GITBOOK-548: change request with no subject merged in GitBook

pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md

@@ -21,7 +21,7 @@ Other ways to support HackTricks:
 Google Workspace's Domain-Wide delegation allows an identity object, either an **external app** from Google Workspace Marketplace or an internal **GCP Service Account**, to **access data across the Workspace on behalf of users**.
 
 {% hint style="info" %}
-This basically means that **service accounts** inside GCP projects or an organization might be able to i**mpersonate Workspace users** of the same organizaiton (or even from a different one).
+This basically means that **service accounts** inside GCP projects of an organization might be able to i**mpersonate Workspace users** of the same organization (or even from a different one).
 {% endhint %}
 
 For more information about how this exactly works check:
@@ -32,8 +32,13 @@ For more information about how this exactly works check:
 
 ### Compromise existing delegation
 
-If an attacker compromised some access over GCP and has a list of valid Workspace users of the company, he could **enumerate** all the **projects** he has access to, **enumerate** all the **SAs** of the projects, **try** to **impersonate** each **service account**, and **repeat** all these **steps** with **each SA** he can impersonate.\
-With a **list of all the service accounts** he has **access** to and the list of **Workspace** **emails**, the attacker could try to **impersonate each user with each service account**.
+If an attacker **compromised some access over GCP** and **known a valid Workspace user email** (preferably **super admin**) of the company, he could **enumerate all the projects** he has access to, **enumerate all the SAs** of the projects, check to which **service accounts he has access to**, and **repeat** all these steps with each SA he can impersonate.\
+With a **list of all the service accounts** he has **access** to and the list of **Workspace** **emails**, the attacker could try to **impersonate user with each service account**.
+
+{% hint style="danger" %}
+Note that when configuring the domain wide delegation no Workspace user is needed, therefore just know **one valid one is enough and required for the impersonation**.\
+However, the **privileges of the impersonated user will be used**, so if it's Super Admin you will be able to access everything. If it doesn't have any access this will be useless.
+{% endhint %}
 
 #### [**DeleFriend**](https://github.com/axon-git/DeleFriend)
 
@@ -53,6 +58,9 @@ This is a tool that can perform the attack following these steps:
 Gitlab've created [this Python script](https://gitlab.com/gitlab-com/gl-security/gl-redteam/gcp\_misc/blob/master/gcp\_delegation.py) that can do two things - list the user directory and create a new administrative account while indicating a json with SA credentials and the user to impersonate. Here is how you would use it:
 
 ```bash
+# Install requirements
+pip install --upgrade --user oauth2client
+
 # Validate access only
 ./gcp_delegation.py --keyfile ./credentials.json \
     --impersonate steve.admin@target-org.com \
@@ -73,15 +81,17 @@ Gitlab've created [this Python script](https://gitlab.com/gitlab-com/gl-security
 
 ### Create a new delegation (Persistence)
 
+It's possible to **check Domain Wide Delegations in** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**
+
 An attacker with the ability to **create service accounts in a GCP project** and **super admin privilege to GWS could create a new delegation allowing SAs to impersonate some GWS users:**
 
 1. **Generating a New Service Account and Corresponding Key Pair:** On GCP, new service account resources can be produced either interactively via the console or programmatically using direct API calls and CLI tools. This requires the **role `iam.serviceAccountAdmin`** or any custom role equipped with the **`iam.serviceAccounts.create`** **permission**. Once the service account is created, we'll proceed to generate a **related key pair** (**`iam.serviceAccountKeys.create`** permission).
-2.  **Creation of new delegation**: After having a relevant identity object and a related private key that enables authentication with Google APIs, we need to **establish a new delegation rule for the service account resource within Google Workspace**. This delegation rule will enable us to perform the Google APIs activity on Workspace REST API applications. It's important to understand that **only the Super Admin role possesses the capability to set up global Domain-Wide delegation in Google Workspace** and Domain-Wide delegation **cannot be set up programmatically,** It can only be created and adjusted **manually** through the Google Workspace **console**.
-
-    The creation of the rule can be found under the page **API controls → Manage Domain-Wide delegation in Google Workspace Admin console**.
-3. **Attaching OAuth scopes privilege**: When configuring a new delegation, Google requires only 2 parameters, the Client ID, which is the **OAuth ID of the GCP Service Account** resource, and **OAuth scopes** that define what API calls the delegation requires.\
-   The **full list of OAuth scopes** can be found [**here**](https://developers.google.com/identity/protocols/oauth2/scopes).
+2. **Creation of new delegation**: It's important to understand that **only the Super Admin role possesses the capability to set up global Domain-Wide delegation in Google Workspace** and Domain-Wide delegation **cannot be set up programmatically,** It can only be created and adjusted **manually** through the Google Workspace **console**.
+   * The creation of the rule can be found under the page **API controls → Manage Domain-Wide delegation in Google Workspace Admin console**.
+3. **Attaching OAuth scopes privilege**: When configuring a new delegation, Google requires only 2 parameters, the Client ID, which is the **OAuth ID of the GCP Service Account** resource, and **OAuth scopes** that define what API calls the delegation requires.
+   * The **full list of OAuth scopes** can be found [**here**](https://developers.google.com/identity/protocols/oauth2/scopes), but here is a recommendation: `https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, openid`
 4. **Acting on behalf of the target identity:** At this point, we have a functioning delegated object in GWS. Now, **using the GCP Service Account private key, we can perform API calls** (in the scope defined in the OAuth scope parameter) to trigger it and **act on behalf of any identity that exists in Google Workspace**. As we learned, the service account will generate access tokens per its needs and according to the permission he has to REST API applications.
+   * Check the **previous section** for some **tools** to use this delegation.
 
 #### Cross-Organizational delegation
 
@@ -112,7 +122,7 @@ gcloud organizations list
 gcloud identity groups memberships search-transitive-groups --member-email <email> --labels=cloudidentity.googleapis.com/groups.discussion_forum
 
 # FROM HERE THE USER NEEDS TO HAVE ENOUGH WORKSPACE ACCESS
-gcloud beta identity groups preview --customer C01cr71rl
+gcloud beta identity groups preview --customer <org-cust-id>
 ```
 {% endcode %}
 
@@ -126,11 +136,11 @@ Check **more enumeration in**:
 
 ### Access privileged GCP users
 
-If an attacker has compete access over GWS he will be able to access groups with privilege access over GCP or even users, therefore moving from GWS to GCP is usually more "simple" just because **users in GWS have high privileges over GCP**.&#x20;
+If an attacker has complete access over GWS he will be able to access groups with privilege access over GCP or even users, therefore moving from GWS to GCP is usually more "simple" just because **users in GWS have high privileges over GCP**.&#x20;
 
 ### Google Groups Privilege Escalation
 
-By default users can freely join Workspace groups of the Organization and those groups might have GCP permissions assigned.
+By default users can **freely join Workspace groups of the Organization** and those groups **might have GCP permissions** assigned (check your groups in [https://groups.google.com/](https://groups.google.com/)).
 
 Abusing the **google groups privesc** you might be able to escalate to a group with some kind of privileged access to GCP.
 

pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/gcp-understanding-domain-wide-delegation.md

@@ -14,7 +14,7 @@ Other ways to support HackTricks:
 
 </details>
 
-This post is a summary of the one from [https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover](https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover) which can be accessed for more details.
+This post is the introduction of [https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover](https://www.hunters.security/en/blog/delefriend-a-newly-discovered-design-flaw-in-domain-wide-delegation-could-leave-google-workspace-vulnerable-for-takeover) which can be accessed for more details.
 
 ## **Understanding Domain-Wide Delegation**
 
@@ -37,10 +37,6 @@ This is how a GCP Service Account can access Google APIs on behalf of other iden
 4. **The Identity uses the access token to call Google APIs**: Now with a relevant access token, the service can access the required REST API. The application uses this access token in the "Authorization" header of its HTTP requests destined for Google APIs. These APIs utilize the token to verify the impersonated identity and confirm it has the necessary authorization.
 5. **Google APIs return the requested data**: If the access token is valid and the service account has appropriate authorization, the Google APIs return the requested data. For example, in the following picture, we’ve leveraged the _users.messages.list_ method to list all the Gmail message IDs associated with a target Workspace user.
 
-
-
-
-
 <details>
 
 <summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>