GWS - Google Platforms Phishing

Tip

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

Sostieni HackTricks

Metodologia Generica di Phishing

Phishing Methodology - HackTricks

Google Groups Phishing

Apparentemente, di default, in Workspace i membri possono creare gruppi e invitare persone in essi. Puoi poi modificare l’email che sarà inviata all’utente aggiungendo alcuni link. L’email arriverà da un indirizzo Google, quindi sembrerà legittima e le persone potrebbero cliccare sul link.

È anche possibile impostare l’indirizzo FROM come la Google group email per inviare più email agli utenti all’interno del gruppo, come nell’immagine seguente dove il gruppo google--support@googlegroups.com è stato creato e un email è stata inviata a tutti i membri del gruppo (aggiunti senza alcun consenso)

Google Chat Phishing

Potresti riuscire a iniziare una chat con una persona avendo solo il suo indirizzo email o inviare un invito a parlare. Inoltre, è possibile creare uno Space che può avere qualsiasi nome (es. “Google Support”) e invitare membri. Se accettano potrebbero pensare di stare parlando con Google Support:

Tip

Nei miei test, però, i membri invitati non hanno nemmeno ricevuto l’invito.

Puoi vedere come funzionava in passato su: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s

Google Doc Phishing

In passato era possibile creare un documento apparentemente legittimo e poi in un commento menzionare un’email (es. @user@gmail.com). Google inviava un’email a quell’indirizzo notificando che erano stati menzionati nel documento.
Oggi questo non funziona, ma se dai all’email della vittima l’accesso al documento Google invierà un’email che lo indica. Questo è il messaggio che appare quando menzioni qualcuno:

Tip

Le vittime potrebbero avere meccanismi di protezione che non permettono che le email che indicano che un documento esterno è stato condiviso con loro arrivino alla loro casella.

Google Calendar Phishing

Puoi creare un evento del calendario e aggiungere quanti indirizzi email dell’azienda che stai attaccando vuoi. Pianifica questo evento del calendario tra 5 o 15 minuti dall’orario corrente. Fai sembrare l’evento legittimo e inserisci un commento e un titolo che indichino che devono leggere qualcosa (con il phishing link).

Questo è l’avviso che apparirà nel browser con un titolo della riunione “Firing People”, quindi potresti impostare un titolo più da phishing (e persino cambiare il nome associato alla tua email).

Per renderlo meno sospetto:

  • Configuralo in modo che i destinatari non possano vedere le altre persone invitate
  • NON inviare email di notifica dell’evento. Così, le persone vedranno solo l’avviso della riunione tra 5 minuti e che devono leggere quel link.
  • Apparentemente usando l’API puoi impostare a True che le persone hanno accettato l’evento e persino creare commenti per conto loro.

App Scripts Redirect Phishing

È possibile creare uno script su https://script.google.com/ ed esporlo come web application accessibile da chiunque che utilizzerà il dominio legittimo script.google.com.
Con un codice come il seguente un attacker potrebbe far caricare contenuto arbitrario in questa pagina senza smettere di accedere al dominio:

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

Nota che apparirà un avviso poiché il contenuto viene caricato all’interno di un iframe.

App Scripts OAuth Phishing

È possibile creare App Scripts collegati ai documenti per cercare di ottenere accesso al token OAuth di una vittima; per maggiori informazioni consulta:

GWS - App Scripts

OAuth Apps Phishing

Qualsiasi delle tecniche precedenti potrebbe essere usata per far sì che l’utente acceda a una Google OAuth application che richiederà all’utente alcuni accessi. Se l’utente si fida della sorgente, potrebbe fidarsi dell’application (anche se sta chiedendo permessi con elevati privilegi).

Note

Nota che Google mostra un prompt poco chiaro che avverte che l’applicazione non è attendibile in diversi casi e gli amministratori di Workspace possono anche impedire agli utenti di accettare applicazioni OAuth.

Google permette di creare applicazioni che possono agire per conto degli utenti su diversi servizi Google: Gmail, Drive, GCP…

Quando si crea un’applicazione per agire per conto di altri utenti, lo sviluppatore deve creare un OAuth app inside GCP e indicare gli scope (permessi) di cui l’app ha bisogno per accedere ai dati degli utenti.
Quando un utente vuole usare quell’applicazione, gli verrà chiesto di accettare che l’app abbia accesso ai dati specificati negli scope.

Questo è un modo molto ghiotto per phishare utenti non tecnici inducendoli a usare application che accedono a informazioni sensibili, perché potrebbero non comprendere le conseguenze. Tuttavia, negli account organizzativi ci sono modi per prevenire che ciò accada.

Unverified App prompt

Come già accennato, Google presenterà sempre un prompt all’utente per accettare i permessi che sta concedendo all’applicazione per suo conto. Tuttavia, se l’app viene considerata pericolosa, Google mostrerà prima un prompt che indica che è pericolosa e rende più difficile per l’utente concedere i permessi all’app.

Questo prompt appare in app che:

  • Usano qualsiasi scope che possa accedere a dati privati (Gmail, Drive, GCP, BigQuery…)
  • App con meno di 100 utenti (per app > 100 è richiesto anche un processo di review per smettere di mostrare l’unverified prompt)

Interesting Scopes

Here 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 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 potrebbe essere interessante se hai già compromesso un utente dell’organizzazione e stai creando questa App per phishare un altro.
  1. Give a name to the app, a support email (nota che puoi impostare un indirizzo googlegroup per cercare di anonimizzarti un po’ di più), un logo, authorized domains e un altro email per updates.
  2. Select the OAuth scopes.
  • Questa pagina è divisa in permessi non sensibili, permessi sensibili e permessi restricted. Ogni volta che aggiungi un nuovo permission viene inserito nella sua categoria. A seconda dei permessi richiesti appariranno prompt diversi all’utente che indicano quanto sono sensibili questi permessi.
  • Sia admin.directory.user.readonly che cloud-platform sono permessi sensibili.
  1. Add the test users. Finché lo stato dell’app è testing, solo questi utenti potranno accedere all’app, quindi assicurati di aggiungere l’email che intendi phishare.

Ora otteniamo le credentials for a web application usando il precedentemente creato OAuth Client ID:

  1. Torna a https://console.cloud.google.com/apis/credentials/oauthclient, questa volta apparirà un’opzione diversa.
  2. Seleziona di create credentials for a Web application
  3. Imposta i necessari Javascript origins e redirect URIs
  • Per i test puoi impostare in entrambi qualcosa come http://localhost:8000/callback
  1. Ottieni le credentials della tua applicazione

Infine, esegui una web application che utilizzi le credenziali dell’OAuth application. Puoi trovare un esempio in 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>"

Vai su http://localhost:8000, clicca sul pulsante Login with Google, ti verrà mostrato un messaggio come questo:

L’applicazione mostrerà gli access and refresh token che possono essere facilmente utilizzati. Per maggiori informazioni su how to use these tokens check:

GCP - Token Persistence

Using glcoud

È possibile fare alcune operazioni usando gcloud invece della console web, consulta:

GCP - ClientAuthConfig Privesc

OAuth app protections

Per impostazione predefinita è configurato che qualsiasi utente all’interno di un’organizzazione Workspace can accecpt any OAuth app with any permissions, ma è possibile limitarle solo alle app che richiedono le informazioni di base necessarie per Sign in with Google o non consentire alcuna third-party app.

Inoltre, anche non permettendo la fiducia verso external third-party apps, è possibile consentire di trust any internal apps (app create all’interno dell’organizzazione). Questa trust è configurata di default.

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

Quando un utente autorizza un OAuth app, Google Workspace lo registra in Admin Reports OAuth Token Audit Activity (application name token) con events.name impostato su authorize. Questi eventi sono la migliore telemetria per rilevare consent phishing e tracciare il client ID e gli scopes che sono stati concessi.

Campi chiave da estrarre dall’evento di audit:

  • id.time, id.customerId
  • actor.email, actor.profileId
  • ipAddress, networkInfo.regionCode, networkInfo.subdivisionCode
  • events[0]['parameters'] valori per client_id, app_name, scope, scope_data

Baseline first (reduce noise): costruisci un inventario dei client IDs e degli scopes esistenti, poi genera alert su consents nuovi/raramente usati.

gam all users print tokens todrive

Idee per il rilevamento (new/rare app + risky scopes):

  • Avvisa se un client_id è non in una allowlist approvata e non è stato visto negli ultimi X giorni (es., 90).
  • Avvisa se il scope concesso include scope ad alto rischio o rari, specialmente quelli che permettono accesso massivo ai dati o impatto sulla supply-chain, come:
  • 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)

Risposta / contenimento:

  • Revoca i token per l’OAuth client ID malevolo:
gam all users delete tokens clientId <client_id>
  • Bloccare l’OAuth client ID nella Admin Console revocando l’accesso dell’applicazione ai dati Google.

Pivot di threat hunting:

  • Elenca le app esterne a cui hanno acconsentito meno di N utenti (adozione rara).
  • Esamina il nome dell’app, il publisher, i permessi/scopes e l’ID univoco dell’applicazione.
  • Cerca app inattive che improvvisamente utilizzano permessi rischiosi (possibili azioni successive come internal phishing o data theft).

Mitigazioni:

  • Limitare l’accesso di tutte le app di terze parti (consentite solo se approvate dall’amministratore).
  • Consentire accesso limitato in modo che gli utenti possano acconsentire solo alle informazioni di base del profilo “Sign in with Google”.

Riferimenti

Tip

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

Sostieni HackTricks