diff --git a/.gitbook/assets/image (153).png b/.gitbook/assets/image (153).png
new file mode 100644
index 0000000000..e9a307fc7f
Binary files /dev/null and b/.gitbook/assets/image (153).png differ
diff --git a/pentesting-cloud/gcp-security/gcp-persistence/gcp-non-svc-persistance.md b/pentesting-cloud/gcp-security/gcp-persistence/gcp-non-svc-persistance.md
index 4e73eb7290..3c3acdc500 100644
--- a/pentesting-cloud/gcp-security/gcp-persistence/gcp-non-svc-persistance.md
+++ b/pentesting-cloud/gcp-security/gcp-persistence/gcp-non-svc-persistance.md
@@ -70,7 +70,7 @@ Note that the communication with localhost is in HTTP, so it it's possible to in
 
 ### OAuth Scopes
 
-Get all the OAuth scopes executing:
+You can find all Google scopes in [https://developers.google.com/identity/protocols/oauth2/scopes](https://developers.google.com/identity/protocols/oauth2/scopes) or get them executing:
 
 {% code overflow="wrap" %}
 ```bash
@@ -78,6 +78,34 @@ curl "https://developers.google.com/identity/protocols/oauth2/scopes" | grep -oE
 ```
 {% endcode %}
 
+It's possible to see which scopes the application that **`gcloud`** uses to authenticate can support with this script:
+
+```bash
+curl "https://developers.google.com/identity/protocols/oauth2/scopes" | grep -oE 'https://www.googleapis.com/auth/[a-zA-Z/\._\-]*' | sort -u | while read -r scope; do 
+    echo -ne "Testing $scope         \r"
+    if ! curl -v "https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=32555940559.apps.googleusercontent.com&redirect_uri=http%3A%2F%2Flocalhost%3A8085%2F&scope=openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+$scope+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fsqlservice.login+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth&state=AjvFqBW5XNIw3VADagy5pvUSPraLQu&access_type=offline&code_challenge=IOk5F08WLn5xYPGRAHP9CTGHbLFDUElsP551ni2leN4&code_challenge_method=S256" 2>&1 | grep -q "error"; then
+        echo ""
+        echo $scope
+    fi
+done
+```
+
+After executing it it was checked that this app supports these scopes:
+
+```
+https://www.googleapis.com/auth/appengine.admin
+https://www.googleapis.com/auth/bigquery
+https://www.googleapis.com/auth/cloud-platform
+https://www.googleapis.com/auth/compute
+https://www.googleapis.com/auth/devstorage.full_control
+https://www.googleapis.com/auth/drive
+https://www.googleapis.com/auth/userinfo.email
+```
+
+it's interesting to see how this app supports the **`drive`** scope, which could allow a user to escalate from GCP to Workspace if an attacker manages to force the user to generate a token with this scope.
+
+**Check how to** [**abuse this here**](../gcp-to-workspace-pivoting/#abusing-gcloud)**.**
+
 ### Service Accounts
 
 Just like with authenticated users, if you manage to **compromise the private key file** of a service account you will be able to **access it usually as long as you want**.\
diff --git a/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md b/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
index 4d0721efcd..887fb0cf29 100644
--- a/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
+++ b/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
@@ -132,6 +132,31 @@ Check **more enumeration in**:
 [gcp-iam-and-org-policies-enum.md](../gcp-services/gcp-iam-and-org-policies-enum.md)
 {% endcontent-ref %}
 
+### Abusing Gcloud
+
+You can find further information about the `gcloud` flow to login in:
+
+{% content-ref url="../gcp-persistence/gcp-non-svc-persistance.md" %}
+[gcp-non-svc-persistance.md](../gcp-persistence/gcp-non-svc-persistance.md)
+{% endcontent-ref %}
+
+As explained there, gcloud can request the scope `https://www.googleapis.com/auth/drive` which would allow a user to access the drive of the user.\
+As an attacker, if you have compromised **physically** the computer of a user and the **user is still logged** with his account you could login generating a token with access to drive using:
+
+```bash
+gcloud auth login --enable-gdrive-access
+```
+
+If an attacker compromises the computer of a user he could also modify the file `google-cloud-sdk/lib/googlecloudsdk/core/config.py` and add in the **`CLOUDSDK_SCOPES`** the scope **`'https://www.googleapis.com/auth/drive'`**:
+
+<figure><img src="../../../.gitbook/assets/image (153).png" alt="" width="563"><figcaption></figcaption></figure>
+
+{% hint style="warning" %}
+Therefore, the next time the user logs in he will create a **token with access to drive** that the attacker could abuse to access the drive. Obviously, the browser will indicate that the generated token will have access to drive, but as the user will call himself the **`gcloud auth login`**, he probably **won't suspect anything.**
+
+To list drive files: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**
+{% endhint %}
+
 ## From GWS to GCP
 
 ### Access privileged GCP users