f

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-misc-perms-privesc.md

@@ -7,7 +7,7 @@
 ### \*.setIamPolicy
 
 If you owns a user that has the **`setIamPolicy`** permission in a resource you can **escalate privileges in that resource** because you will be able to change the IAM policy of that resource and give you more privileges over it.\
-This permission can also allow to **escalate to other principals** if the resource allow to execute code and the iam.ServiceAccounts.actAs is not necessary.
+This permission can also allow to **escalate to other principals** if the resource allow to execute code and the `iam.ServiceAccounts.actAs` is not necessary.
 
 - _cloudfunctions.functions.setIamPolicy_
   - Modify the policy of a Cloud Function to allow yourself to invoke it.
@@ -22,6 +22,13 @@ These permissions can be very useful to try to escalate privileges in resources
 
 This permission will usually let you **access or modify a Service Account in some resource** (e.g.: compute.instances.setServiceAccount). This **could lead to a privilege escalation** vector, but it will depend on each case.
 
+### iam.ServiceAccounts.actAs
+
+This permission will let you attach a Service Account to a resource that supports it (e.g.: Compute Engine VM, Cloud Function, Cloud Run, etc).\
+If you can attach a Service Account that has more privileges than your user to a resource that can execute code, you will be able to escalate your privileges by executing code with that Service Account.
+
+Search in Cloud Hacktricks for `iam.ServiceAccounts.actAs` to find several examples of how to escalate privileges with this permission.
+
 {{#include ../../../banners/hacktricks-training.md}}
 
 

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-orgpolicy-privesc.md

@@ -18,6 +18,33 @@ gcloud resource-manager org-policies disable-enforce <org-policy> [--folder <id>
 
 A python script for this method can be found [here](https://github.com/RhinoSecurityLabs/GCP-IAM-Privilege-Escalation/blob/master/ExploitScripts/orgpolicy.policy.set.py).
 
+### `orgpolicy.policy.set`, `iam.serviceAccounts.actAs`
+
+uusally it's not possible to attach a service account from a different project to a resource becasue there is a policy constraint enforced named **`iam.disableCrossProjectServiceAccountUsage`** that prevents this action.
+
+It's possible to verify if this constraint is enforced by running the following command:
+
+```bash
+gcloud resource-manager org-policies describe \
+  constraints/iam.disableCrossProjectServiceAccountUsage \
+  --project=<project-id> \
+  --effective
+
+booleanPolicy:
+  enforced: true
+constraint: constraints/iam.disableCrossProjectServiceAccountUsage
+```
+
+This prevents an attacker from abusing the permission **`iam.serviceAccounts.actAs`** to impersonate a service account from another project without needed further infra permissions to start a new VM for example, which could lead to privilege escalation.
+
+However, an attacker with the permissions **`orgpolicy.policy.set`** can bypass this restriction by disabling the constraint **`iam.disableServiceAccountProjectWideAccess`**. This allows the attacker to attach a service account from another project to a resource in his own project, effectively escalating his privileges.
+
+```bash
+gcloud resource-manager org-policies disable-enforce \
+  iam.disableCrossProjectServiceAccountUsage \
+  --project=<project-id>
+```
+
 ## References
 
 - [https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/](https://rhinosecuritylabs.com/cloud-security/privilege-escalation-google-cloud-platform-part-2/)