GWS - Google Platforms Phishing

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Generiese Phishing Methodology

Phishing Methodology - HackTricks

Google Groups Phishing

Skynbaar, standaard kan workspace-lede can create groups and invite people to them. Jy kan dan die e-pos wat aan die gebruiker gestuur sal word wysig deur ’n paar skakels by te voeg. Die e-pos sal van ’n google adres kom, so dit sal legit lyk en mense mag op die skakel klik.

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)

Google Chat Phishing

Jy kan moontlik óf ’n klets begin met ’n persoon slegs met hul e-posadres óf ’n uitnodiging om te praat stuur. Verder is dit moontlik om ’n Space te skep wat enige naam kan hê (bv. “Google Support”) en lede daaraan uit te nooi. As hulle aanvaar, mag hulle dink dat hulle met Google Support praat:

Tip

In my testing however the invited members didn’t even receive an invitation.

Jy kan sien hoe dit voorheen gewerk het by: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s

Google Doc Phishing

In die verlede was dit moontlik om ’n skynbaar legitime dokument te skep en dan in ’n kommentaar ’n e-posadres te noem (bv. @user@gmail.com). Google het ’n e-pos na daardie e-posadres gestuur om te rapporteer dat hulle in die dokument genoem is.
Tans werk dit nie meer nie, maar as jy die slagoffer e-postoegang tot die dokument gee, sal Google ’n e-pos stuur wat dit aandui. Dit is die boodskap wat verskyn wanneer jy iemand noem:

Tip

Slagoffers kan beskermingsmeganismes hê wat nie toelaat dat e-posse wat aandui dat ’n eksterne dokument met hulle gedeel is, by hul e-pos aankom nie.

Google Calendar Phishing

Jy kan ’n kalendergebeurtenis skep en soveel e-posadresse van die maatskappy wat jy aanval byvoeg as wat jy het. Skeduleer hierdie kalendergebeurtenis oor 5 of 15 min van nou af. Laat die gebeurtenis legitim lyk en sit ’n kommentaar en ’n titel wat aandui dat hulle iets moet lees (met die phishing link).

Dit is die waarskuwing wat in die blaaier sal verskyn met die vergaderingstitel “Firing People”, so jy kan ’n meer phishing-agtige titel stel (en selfs die naam wat met jou e-pos geassosieer word verander).

Om dit minder verdag te laat lyk:

  • Stel dit so in dat ontvangers nie die ander uitgenooi persone kan sien nie
  • Moet NIET e-posse stuur wat oor die gebeurtenis inlig nie. Dan sal die mense net hul waarskuwing oor ’n vergadering oor 5 minute sien en dat hulle daardie skakel moet lees.
  • Klaarblyklik kan jy deur die API te gebruik op True stel dat mense die gebeurtenis aanvaar het en selfs kommentaar namens hulle skep.

App Scripts Redirect Phishing

Dit is moontlik om ’n script te skep op https://script.google.com/ en dit as ’n webtoepassing wat deur almal toeganklik is bloot te stel wat die legit domein script.google.com sal gebruik.
Met ’n paar reëls kode soos die volgende kan ’n aanvaller die script laat laai arbitrêre inhoud op hierdie blad sonder om die domaine te verlaat:

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 you will see:

Tip

Let wel dat ’n waarskuwing sal verskyn omdat die inhoud binne ’n iframe gelaai word.

App Scripts OAuth Phishing

Dit is moontlik om App Scripts aan dokumente te koppel om te probeer toegang te kry tot die slagoffer se OAuth-token; vir meer inligting, sien:

GWS - App Scripts

OAuth Apps Phishing

Enige van die vorige tegnieke kan gebruik word om die gebruiker te laat toegang kry tot ’n Google OAuth application wat die gebruiker sekere access sal request. As die gebruiker die source trusts, kan hy dalk ook die application vertrou (selfs al vra dit hoogs bevoorregte toestemmings).

Note

Let wel dat Google in verskeie gevalle ’n opvallende waarskuwing wys wat aandui dat die toepassing onbetroubaar is, en Workspace-admins kan selfs verhinder dat mense OAuth applications aanvaar.

Google laat toe om toepassings te skep wat namens gebruikers met verskeie Google services kan werk: Gmail, Drive, GCP…

Wanneer ’n ontwikkelaar ’n toepassing skep om namens ander gebruikers te optree, moet hy ’n OAuth app inside GCP skep en die scopes (toestemmings) aandui wat die app benodig om toegang tot die gebruiker se data te kry. Wanneer ’n user daardie application wil use, sal hulle prompted word om te accept dat die toepassing toegang tot hul data sal hê soos in die scopes gespesifiseer.

Dit is ’n baie doeltreffende manier om nie-tegniese gebruikers te phish om toepassings te gebruik wat toegang tot sensitiewe inligting het, omdat hulle moontlik nie die gevolge verstaan nie. In organisasie-rekeninge bestaan daar egter metodes om dit te verhoed.

Unverified App prompt

Soos genoem, sal Google altyd ’n prompt to the user to accept die toestemmings wat hulle namens hulle aan die toepassing gee. As die toepassing egter as dangerous beskou word, sal Google eers ’n prompt wys wat aandui dat dit dangerous is en dit vir die gebruiker moeiliker maak om die toestemmings aan die app te verleen.

This prompt appears in apps that:

  • Use any scope that can access private data (Gmail, Drive, GCP, BigQuery…)
  • Apps with less than 100 users (vir apps met > 100 gebruikers is ’n review-proses ook nodig om die unverified prompt te laat ophou verskyn)

Interesting Scopes

Hier you can find a list of all the Google OAuth scopes.

  • cloud-platform: Sien en bestuur jou data oor Google Cloud Platform-dienste. Jy kan die gebruiker in GCP naboots/namens die gebruiker optree.
  • admin.directory.user.readonly: Sien en aflaai jou organisasie se GSuite-gids. Kry name, telefoonnommers en kalender-URL’s van alle gebruikers.

Create an OAuth App

Start creating an OAuth Client ID

  1. Gaan na https://console.cloud.google.com/apis/credentials/oauthclient en klik op ‘configure the consent screen’.
  2. Daarna sal jy gevra word of die user type internal (slegs vir mense in jou org) of external is. Kies die een wat by jou behoeftes pas.
  • Internal kan interessant wees as jy reeds ’n gebruiker van die organisasie gekompromitteer het en jy hierdie App skep om nog ’n gebruiker te phish.
  1. Gee ’n name aan die app, ’n support email (let wel: jy kan ’n googlegroup email gebruik om jou identiteit effens te anonimiseer), ’n logo, authorized domains en nog ’n email vir updates.
  2. Select die OAuth scopes.
  • Hierdie bladsy is verdeel in non sensitive permissions, sensitive permissions en restricted permissions. Elke keer wat jy ’n nuwe permission byvoeg, word dit in sy kategorie geplaas. Afhangend van die versoekte permissions sal verskillende prompts aan die gebruiker vertoon word wat aandui hoe sensitief daardie permissions is.
  • Beide admin.directory.user.readonly en cloud-platform is sensitive permissions.
  1. Add the test users. Solank die app se status op testing is, sal net daardie gebruikers toegang tot die app hê — maak dus seker jy add the email you are going to be phishing.

Nou kry ons credentials for a web application met behulp van die previously created OAuth Client ID:

  1. Gaan terug na https://console.cloud.google.com/apis/credentials/oauthclient; ’n verskillende opsie sal hierdie keer verskyn.
  2. Kies om create credentials for a Web application.
  3. Stel die nodige Javascript origins en redirect URIs in.
  • Jy kan in albei iets soos http://localhost:8000/callback vir toetsing gebruik.
  1. Kry jou application credentials.

Laastens, laat ons ’n web application laat loop wat die OAuth application credentials sal gebruik. Jy kan ’n voorbeeld vind by https://github.com/carlospolop/gcp_oauth_phishing_example.

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>"

Gaan na http://localhost:8000, klik op die Login with Google-knoppie, jy sal ’n boodskap soos hierdie sien:

Die toepassing sal die access and refresh token wys wat maklik gebruik kan word. Vir meer inligting oor hoe om hierdie tokens te gebruik, sien:

GCP - Token Persistence

Using glcoud

Dit is moontlik om iets met gcloud te doen in plaas van die webkonsol, sien:

GCP - ClientAuthConfig Privesc

OAuth app protections

Volgens verstek is dit gekonfigureer sodat enige gebruiker binne ’n Workspace-organisasie can accecpt any OAuth app with any permissions, maar dit is moontlik om dit te beperk tot slegs apps wat net die basiese inligting wat vir Sign in with Google nodig is versoek, of om geen derdeparty-apps toe te laat nie.

Verder, selfs al word dit nie toegelaat om eksterne derdeparty-apps te vertrou nie, is dit moontlik om te vertrou enige interne apps (apps geskep binne die organisasie). Hierdie vertroue is by verstek gekonfigureer.

OAuth Consent Grant Abuse: Opsporing & Respons (Admin Reports)

Wanneer ’n gebruiker ’n OAuth app magtig, teken Google Workspace dit op in die Admin Reports OAuth Token Audit Activity (application name token) met events.name gestel op authorize. Hierdie events is die beste telemetrie om consent phishing te ontdek en die client ID en scopes wat toegeken is, op te spoor.

Sleutelvelde om uit die ouditgebeurtenis te onttrek:

  • 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

Begin met ’n basislyn (verminder geraas): bou ’n inventaris van bestaande client IDs en scopes, en waarsku dan oor nuwe/seldsame toestemmings.

gam all users print tokens todrive

Opsporingsidees (new/rare app + risky scopes):

  • Waarsku as client_id nie in ’n goedgekeurde allowlist is nie en nie in die laaste X dae gesien is nie (bv. 90).
  • Waarsku as die toegekende scope high-risk or rare scopes insluit, veral dié wat bulk data toegang of supply-chain impact moontlik maak, soos:
  • 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
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)

Reaksie / inperking:

  • Herroep tokens vir die kwaadwillige OAuth client ID:
gam all users delete tokens clientId <client_id>
  • Blokkeer die OAuth client ID in die Admin Console deur die toepassing se toegang tot Google-data in te trek.

Threat hunting pivots:

  • Lys external apps waaraan minder as N gebruikers toestemming verleen het (seldsame aanneming).
  • Kontroleer app-naam, publisher, permissions/scopes, en unieke application ID.
  • Soek na dormant apps wat skielik risky permissions begin gebruik (moontlike opvolgaksies soos internal phishing of data theft).

Maatreëls:

  • Beperk alle third-party app access (slegs admin-goedgekeur).
  • Laat beperkte toegang toe sodat gebruikers slegs toestemming kan gee vir basiese “Sign in with Google” profielinligting.

References

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks