# GWS - Google Platforms Phishing

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

## Generic Phishing Methodology

{{#ref}}
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html
{{#endref}}

## Google Groups Phishing

Apparently, by default, in workspace members [**can create groups**](https://groups.google.com/all-groups) **and invite people to them**. You can then modify the email that will be sent to the user **adding some links.** The **email will come from a google address**, so it will look **legit** and people might click on the link.

It's also possible to set the **FROM** address as the **Google group email** to send **more emails to the users inside the group**, like in the following image where the group **`google--support@googlegroups.com`** was created and an **email was sent to all the members** of the group (that were added without any consent)

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

## Google Chat Phishing

You might be able to either **start a chat** with a person just having their email address or send an **invitation to talk**. Moreover, it's possible to **create a Space** that can have any name (e.g. "Google Support") and **invite** members to it. If they accept they might think that they are talking to Google Support:

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

> [!TIP]
> **In my testing however the invited members didn't even receive an invitation.**

You can check how this worked in the past in: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s)

## Google Doc Phishing

In the past it was possible to create an **apparently legitimate document** and the in a comment **mention some email (like @user@gmail.com)**. Google **sent an email to that email address** notifying that they were mentioned in the document.\
Nowadays, this doesn't work but if you **give the victim email access to the document** Google will send an email indicating so. This is the message that appears when you mention someone:

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

> [!TIP]
> Victims might have protection mechanism that doesn't allow that emails indicating that an external document was shared with them reach their email.

## Google Calendar Phishing

You can **create a calendar event** and add as many email address of the company you are attacking as you have. Schedule this calendar event in **5 or 15 min** from the current time. Make the event look legit and **put a comment and a title indicating that they need to read something** (with the **phishing link**).

This is the alert that will appear in the browser with a meeting title "Firing People", so you could set a more phishing like title (and even change the name associated with your email).

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

To make it look less suspicious:

- Set it up so that **receivers cannot see the other people invited**
- Do **NOT send emails notifying about the event**. Then, the people will only see their warning about a meeting in 5mins and that they need to read that link.
- Apparently using the API you can set to **True** that **people** have **accepted** the event and even create **comments on their behalf**.

## App Scripts Redirect Phishing

It's possible to create a script in [https://script.google.com/](https://script.google.com/) and **expose it as a web application accessible by everyone** that will use the legit domain **`script.google.com`**.\
The with some code like the following an attacker could make the script load arbitrary content in this page without stop accessing the domain:

```javascript
function doGet() {
  return HtmlService.createHtmlOutput(
    '<meta http-equiv="refresh" content="0;url=https://cloud.hacktricks.wiki/en/pentesting-cloud/workspace-security/gws-google-platforms-phishing/index.html#app-scripts-redirect-phishing">'
  ).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL)
}
```

For example accessing [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) you will see:

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

> [!TIP]
> Note that a warning will appear as the content is loaded inside an iframe.

## App Scripts OAuth Phishing

It's possible to create App Scripts attached to documents to try to get access over a victims OAuth token, for more information check:

{{#ref}}
gws-app-scripts.md
{{#endref}}

## OAuth Apps Phishing

Any of the previous techniques might be used to make the user access a **Google OAuth application** that will **request** the user some **access**. If the user **trusts** the **source** he might **trust** the **application** (even if it's asking for high privileged permissions).

> [!NOTE]
> Note that Google presents an ugly prompt asking warning that the application is untrusted in several cases and Workspace admins can even prevent people accepting OAuth applications.

**Google** allows to create applications that can **interact on behalf users** with several **Google services**: Gmail, Drive, GCP...

When creating an application to **act on behalf other users**, the developer needs to create an **OAuth app inside GCP** and indicate the scopes (permissions) the app needs to access the users data.\
When a **user** wants to **use** that **application**, they will be **prompted** to **accept** that the application will have access to their data specified in the scopes.

This is a very juicy way to **phish** non-technical users into using **applications that access sensitive information** because they might not understand the consequences. However, in organizations accounts, there are ways to prevent this from happening.

### Unverified App prompt

As it was mentioned, google will always present a **prompt to the user to accept** the permissions they are giving the application on their behalf. However, if the application is considered **dangerous**, google will show **first** a **prompt** indicating that it's **dangerous** and **making it more difficult** for the user to grant the permissions to the app.

This prompt appears in apps that:

- Use any scope that can access private data (Gmail, Drive, GCP, BigQuery...)
- Apps with less than 100 users (apps > 100 a review process is also needed to stop showing the unverified prompt)

### Interesting Scopes

[**Here**](https://developers.google.com/identity/protocols/oauth2/scopes) you can find a list of all the Google OAuth scopes.

- **cloud-platform**: View and manage your data across **Google Cloud Platform** services. You can impersonate the user in GCP.
- **admin.directory.user.readonly**: See and download your organization's GSuite directory. Get names, phones, calendar URLs of all the users.

### Create an OAuth App

**Start creating an OAuth Client ID**

1. Go to [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) and click on configure the consent screen.
2. Then, you will be asked if the **user type** is **internal** (only for people in your org) or **external**. Select the one that suits your needs
   - Internal might be interesting you have already compromised a user of the organization and you are creating this App to phish another one.
3. Give a **name** to the app, a **support email** (note that you can set a googlegroup email to try to anonymize yourself a bit more), a **logo**, **authorized domains** and another **email** for **updates**.
4. **Select** the **OAuth scopes**.
   - This page is divided in non sensitive permissions, sensitive permissions and restricted permissions. Eveytime you add a new permisison it's added on its category. Depending on the requested permissions different prompt will appear to the user indicating how sensitive these permissions are.
   - Both **`admin.directory.user.readonly`** and **`cloud-platform`** are sensitive permissions.
5. **Add the test users.** As long as the status of the app is testing, only these users are going to be able to access the app so make sure to **add the email you are going to be phishing**.

Now let's get **credentials for a web application** using the **previously created OAuth Client ID**:

1. Go back to [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), a different option will appear this time.
2. Select to **create credentials for a Web application**
3. Set needed **Javascript origins** and **redirect URIs**
   - You can set in both something like **`http://localhost:8000/callback`** for testing
4. Get your application **credentials**

Finally, lets **run a web application that will use the OAuth application credentials**. You can find an example in [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).

```bash
git clone ttps://github.com/carlospolop/gcp_oauth_phishing_example
cd gcp_oauth_phishing_example
pip install flask requests google-auth-oauthlib
python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"
```

Go to **`http://localhost:8000`** click on the Login with Google button, you will be **prompted** with a message like this one:

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

The application will show the **access and refresh token** than can be easily used. For more information about **how to use these tokens check**:

{{#ref}}
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
{{#endref}}

#### Using `glcoud`

It's possible to do something using gcloud instead of the web console, check:

{{#ref}}
../../gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md
{{#endref}}

#### OAuth app protections

By default it's configured that any user inside a Workspace organization **can accecpt any OAuth app with any permissions**, but it's possible to restrict those to only apps that only request basic info needed for Sign in with Google or to not allow any third-party apps.

Moreover, even not alowing to trust external third-party apps it's possible to allow to **trust any internal apps** (apps created inside the organization). This trust is configured by **default**.

<figure><img src="../../../images/workspace_oauth.png" alt=""><figcaption></figcaption></figure>

### OAuth Consent Grant Abuse: Detection & Response (Admin Reports)

When a user authorizes an OAuth app, Google Workspace records it in the **Admin Reports OAuth Token Audit Activity** (application name `token`) with `events.name` set to `authorize`. These events are the best telemetry to detect consent phishing and track the client ID and scopes that were granted.

Key fields to extract from the audit event:

- `id.time`, `id.customerId`
- `actor.email`, `actor.profileId`
- `ipAddress`, `networkInfo.regionCode`, `networkInfo.subdivisionCode`
- `events[0]['parameters']` values for `client_id`, `app_name`, `scope`, `scope_data`

**Baseline first (reduce noise):** build an inventory of existing client IDs and scopes, then alert on new/rare consents.

```bash
gam all users print tokens todrive
```

**Detection ideas (new/rare app + risky scopes):**

- Alert if a `client_id` is **not in an approved allowlist** and **not seen in the last X days** (e.g., 90).
- Alert if granted `scope` includes **high-risk or rare** scopes, especially those that allow bulk data access or supply-chain impact, such as:
- `https://mail.google.com/`
- `https://www.googleapis.com/auth/gmail.readonly`
- `https://www.googleapis.com/auth/drive`
- `https://www.googleapis.com/auth/drive.readonly`
- `https://www.googleapis.com/auth/chat.messages`
- `https://www.googleapis.com/auth/chromewebstore`

```text
client_id NOT IN approved_client_ids
AND client_id NOT IN last_seen_90d
AND scope CONTAINS any(high_risk_scopes OR rare_scopes)
```

**Response / containment:**

- Revoke tokens for the malicious OAuth client ID:

```bash
gam all users delete tokens clientId <client_id>
```

- Block the OAuth client ID in the Admin Console by revoking the application’s access to Google data.

**Threat hunting pivots:**

- List external apps consented by fewer than N users (rare adoption).
- Review app name, publisher, permissions/scopes, and unique application ID.
- Look for dormant apps that suddenly use risky permissions (possible follow-on actions like internal phishing or data theft).

**Mitigations:**

- Restrict all third-party app access (admin-approved only).
- Allow limited access so users can only consent to basic “Sign in with Google” profile info.

## References

- [https://www.youtube-nocookie.com/embed/6AsVUS79gLw](https://www.youtube-nocookie.com/embed/6AsVUS79gLw) - Matthew Bryant - Hacking G Suite: The Power of Dark Apps Script Magic
- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch and Beau Bullock - OK Google, How do I Red Team GSuite?
- [https://redcanary.com/blog/threat-detection/google-workspace-oauth-attack/](https://redcanary.com/blog/threat-detection/google-workspace-oauth-attack/)
- [https://github.com/GAM-team/GAM](https://github.com/GAM-team/GAM)

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

