diff --git a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md index f00643d24..7fab4c2db 100644 --- a/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md +++ b/src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md @@ -4,44 +4,44 @@ ## Informazioni di base -Nelle architetture Exchange Hybrid legacy, la distribuzione Exchange on-prem poteva autenticarsi come la stessa identità applicativa Entra utilizzata da Exchange Online. Se un attaccante comprometteva il server Exchange, estraeva la chiave privata del certificato hybrid e eseguiva un OAuth client-credentials flow, poteva ottenere token first-party con il contesto di privilegi di Exchange Online. +Nelle architetture legacy di Exchange Hybrid, la deployment on-prem di Exchange poteva autenticarsi come la stessa identità dell'applicazione Entra usata da Exchange Online. Se un attaccante comprometteva il server Exchange, estraeva la chiave privata del certificato hybrid e eseguiva un OAuth client-credentials flow, poteva ottenere token first-party con il contesto di privilegi di Exchange Online. -Il rischio pratico non si limitava all'accesso alle caselle. Poiché Exchange Online aveva ampie relazioni di trust back-end, questa identità poteva interagire con altri servizi Microsoft 365 e, nei comportamenti più vecchi, poteva essere sfruttata per un compromesso più profondo del tenant. +Il rischio pratico non si limitava all'accesso alle cassette postali. Poiché Exchange Online aveva ampie relazioni di trust back-end, questa identità poteva interagire con altri servizi Microsoft 365 e, nei comportamenti più vecchi, poteva essere sfruttata per un compromesso più profondo del tenant. ## Percorsi d'attacco e flusso tecnico -### Modificare la configurazione di federazione tramite Exchange +### Modificare la configurazione di federation tramite Exchange -Storicamente i token di Exchange avevano permessi per scrivere le impostazioni di dominio/federazione. Dal punto di vista dell'attaccante, questo permetteva la manipolazione diretta dei dati di trust del dominio federato, incluse le liste di certificati per la firma dei token e i flag di configurazione che controllavano l'accettazione delle MFA-claim dall'infrastruttura di federazione on-prem. +Storicamente, i token di Exchange avevano permessi per scrivere le impostazioni di dominio/federation. Dal punto di vista di un attaccante, questo permetteva la manipolazione diretta dei dati di trust dei domini federati, incluse le liste dei certificati per la firma dei token e i flag di configurazione che controllavano l'accettazione delle MFA-claim dall'infrastruttura di federation on-prem. -Ciò significa che un server Exchange Hybrid compromesso poteva essere usato per avviare o rafforzare un'impersonazione in stile ADFS modificando la config di federazione dalla parte cloud, anche quando l'attaccante era partito solo da una compromissione di Exchange on-prem. +Ciò significa che un server Exchange Hybrid compromesso poteva essere usato per orchestrare o rafforzare un'impersonazione in stile ADFS modificando la config di federation dalla parte cloud, anche quando l'attaccante era partito solo da una compromissione di Exchange on-prem. -### ACS Actor Tokens e impersonazione servizio-a-servizio +### ACS Actor Tokens and Service-to-Service Impersonation -Il percorso di autenticazione hybrid di Exchange usava Access Control Service (ACS) actor tokens con `trustedfordelegation=true`. Questi actor token venivano poi incorporati in un secondo service token non firmato che trasportava l'identità dell'utente target in una sezione controllata dall'attaccante. Poiché il token esterno non era firmato e l'actor token delegava ampiamente, il chiamante poteva sostituire gli utenti target senza ri-autenticarsi. +Il percorso di auth hybrid di Exchange usava Access Control Service (ACS) actor tokens con `trustedfordelegation=true`. Quei actor token venivano poi incorporati in un secondo service token non firmato che portava l'identità dell'utente target in una sezione controllata dall'attaccante. Poiché il token esterno non era firmato e l'actor token delegava ampiamente, il chiamante poteva scambiare utenti target senza ri-autenticarsi. -In pratica, una volta ottenuto l'actor token, l'attaccante disponeva di una primitiva di impersonazione a lunga durata (tipicamente circa 24 ore) difficile da revocare a metà vita. Ciò abilitava l'impersonazione di utenti attraverso le API di Exchange Online e SharePoint/OneDrive, includendo esfiltrazione di dati ad alto valore. +In pratica, una volta ottenuto l'actor token, l'attaccante disponeva di una primitiva di impersonazione a lunga durata (tipicamente circa 24 ore) difficile da revocare a metà vita. Questo consentiva l'impersonazione di utenti attraverso le API di Exchange Online e SharePoint/OneDrive, inclusa l'esfiltrazione di dati ad alto valore. -Storicamente, lo stesso pattern funzionava anche contro `graph.windows.net` costruendo un token di impersonazione con il valore `netId` della vittima. Questo forniva azioni amministrative dirette su Entra come utenti arbitrari e permetteva workflow di takeover completo del tenant (per esempio, la creazione di un nuovo account Global Administrator). +Storicamente, lo stesso schema funzionava anche contro `graph.windows.net` costruendo un token di impersonazione con il `netId` della vittima. Ciò permetteva azioni amministrative dirette in Entra come utenti arbitrari e abilitava workflow di takeover dell'intero tenant (per esempio, la creazione di un nuovo account Global Administrator). ## Cosa non funziona più -Il percorso di impersonazione `graph.windows.net` via Exchange Hybrid actor tokens è stato corretto. La vecchia catena "Exchange to arbitrary Entra admin over Graph" dovrebbe essere considerata rimossa per questa specifica via di token. +Il percorso di impersonazione `graph.windows.net` via Exchange Hybrid actor tokens è stato corretto. La vecchia catena "Exchange to arbitrary Entra admin over Graph" dovrebbe essere considerata rimossa per questa specifica route di token. -Questa è la correzione più importante da evidenziare nella documentazione dell'attacco: mantenere il rischio di impersonazione Exchange/SharePoint separato dall'escalation di impersonazione Graph ora patchata. +Questa è la correzione più importante da documentare per l'attacco: mantenere separato il rischio di impersonazione Exchange/SharePoint dall'escalation di impersonazione su Graph ora patchata. -## Cosa può ancora essere rilevante in pratica +## Ciò che può ancora avere importanza nella pratica -Se un'organizzazione esegue ancora una configurazione hybrid vecchia o incompleta con trust condiviso e materiale di certificato esposto, l'impatto dell'impersonazione Exchange/SharePoint può rimanere severo. L'angolo di abuso della configurazione di federazione può anche rimanere rilevante a seconda della configurazione del tenant e dello stato di migrazione. +Se un'organizzazione esegue ancora una configurazione hybrid vecchia o incompleta con trust condiviso e materiale dei certificati esposto, l'impatto dell'impersonazione Exchange/SharePoint può rimanere grave. L'angolo di abuso della configurazione di federation può anche restare rilevante a seconda della configurazione del tenant e dello stato della migrazione. -La mitigazione a lungo termine di Microsoft è separare le identità on-prem e Exchange Online in modo che il percorso di trust del shared-service-principal non esista più. Gli ambienti che hanno completato quella migrazione riducono materialmente questa superficie d'attacco. +La mitigazione a lungo termine di Microsoft è separare le identità on-prem e di Exchange Online in modo che il percorso di trust del shared-service-principal non esista più. Gli ambienti che hanno completato quella migrazione riducono materialmente questa superficie d'attacco. ## Note di rilevamento -Quando questa tecnica viene abusata, gli eventi di audit possono mostrare mismatch di identità in cui lo user principal name corrisponde a un utente impersonato mentre il contesto di display/sorgente indica attività di Exchange Online. Quel pattern di identità mista è un segnale di hunting di alto valore, sebbene i difensori debbano basare una baseline dei workflow legittimi degli Exchange-admin per ridurre i falsi positivi. +Quando questa tecnica viene abusata, gli eventi di audit possono mostrare mismatch di identità in cui lo user principal name corrisponde a un utente impersonato mentre il contesto display/source punta ad attività di Exchange Online. Quel pattern di identità mista è un segnale di hunting ad alto valore, sebbene i defender dovrebbero definire una baseline dei workflow legittimi degli Exchange-admin per ridurre i falsi positivi. ## Riferimenti -- https://www.youtube.com/watch?v=rzfAutv6sB8 +- [https://www.youtube.com/watch?v=rzfAutv6sB8](https://www.youtube.com/watch?v=rzfAutv6sB8) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md b/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md index 5e9fe2663..175c0566a 100644 --- a/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md +++ b/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md @@ -2,7 +2,7 @@ {{#include ../../../banners/hacktricks-training.md}} -## Generic Phishing Methodology +## Metodologia Generica di Phishing {{#ref}} https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html @@ -10,51 +10,51 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met ## Google Groups Phishing -A quanto pare, per impostazione predefinita, nei workspace i membri [**possono creare gruppi**](https://groups.google.com/all-groups) **e invitare persone a farne parte**. Puoi quindi modificare l'email che verrà inviata all'utente **aggiungendo alcuni link.** L'**email verrà inviata da un indirizzo google**, quindi sembrerà **legittima** e le persone potrebbero cliccare sul link. +Apparentemente, di default, in Workspace i membri [**possono creare gruppi**](https://groups.google.com/all-groups) **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 l'**email del gruppo Google** per inviare **ulteriori 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 (che sono stati aggiunti senza alcun consenso) +È 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 essere in grado di **iniziare una chat** con una persona semplicemente avendo il suo indirizzo email o inviare un'**invito a parlare**. Inoltre, è possibile **creare uno Spazio** che può avere qualsiasi nome (ad es. "Google Support") e **invitare** membri a farne parte. Se accettano, potrebbero pensare di stare parlando con il supporto Google: +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] -> **Tuttavia, nei miei test i membri invitati non hanno nemmeno ricevuto un invito.** +> Nei miei test, però, i membri invitati non hanno nemmeno ricevuto l'invito. -Puoi controllare come questo ha funzionato in passato in: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s) +Puoi vedere come funzionava in passato su: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s) ## Google Doc Phishing -In passato era possibile creare un **documento apparentemente legittimo** e in un commento **menzionare un'email (come @user@gmail.com)**. Google **inviava un'email a quell'indirizzo email** notificando che era stato menzionato nel documento.\ -Oggigiorno, questo non funziona più, ma se **dai accesso al documento alla vittima** Google invierà un'email che lo indica. Questo è il messaggio che appare quando menzioni qualcuno: +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 raggiungano la loro email. +> 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 di calendario** e aggiungere quanti più indirizzi email dell'azienda che stai attaccando. Pianifica questo evento di calendario in **5 o 15 minuti** dall'orario attuale. Fai sembrare l'evento legittimo e **metti un commento e un titolo che indicano che devono leggere qualcosa** (con il **link di 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 di riunione "Licenziare persone", quindi potresti impostare un titolo più simile al phishing (e persino cambiare il nome associato alla tua email). +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 farlo sembrare meno sospetto: +Per renderlo meno sospetto: -- Impostalo in modo che **i destinatari non possano vedere le altre persone invitate** -- **NON inviare email che notificano l'evento**. Così, le persone vedranno solo il loro avviso riguardo a una riunione tra 5 minuti e che devono leggere quel link. -- A quanto pare, utilizzando l'API puoi impostare su **True** che **le persone** hanno **accettato** l'evento e persino creare **commenti a loro nome**. +- 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 in [https://script.google.com/](https://script.google.com/) e **esporlo come un'applicazione web accessibile a tutti** che utilizzerà il dominio legittimo **`script.google.com`**.\ -Con un codice come il seguente, un attaccante potrebbe far caricare contenuti arbitrari in questa pagina senza smettere di accedere al dominio: +È possibile creare uno script su [https://script.google.com/](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: ```javascript function doGet() { return HtmlService.createHtmlOutput( @@ -62,16 +62,16 @@ return HtmlService.createHtmlOutput( ).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL) } ``` -Per esempio, accedendo a [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) vedrai: +For example accessing [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) you will see:
> [!TIP] -> Nota che apparirà un avviso mentre il contenuto viene caricato all'interno di un iframe. +> Nota che apparirà un avviso poiché il contenuto viene caricato all'interno di un iframe. ## App Scripts OAuth Phishing -È possibile creare App Scripts collegati a documenti per cercare di ottenere accesso al token OAuth di una vittima, per ulteriori informazioni controlla: +È possibile creare App Scripts collegati ai documenti per cercare di ottenere accesso al token OAuth di una vittima; per maggiori informazioni consulta: {{#ref}} gws-app-scripts.md @@ -79,83 +79,142 @@ gws-app-scripts.md ## OAuth Apps Phishing -Qualsiasi delle tecniche precedenti potrebbe essere utilizzata per far accedere l'utente a un **Google OAuth application** che **richiederà** all'utente alcuni **accessi**. Se l'utente **si fida** della **fonte**, potrebbe **fidarsi** dell'**applicazione** (anche se sta chiedendo permessi ad alta privilegio). +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 presenta un brutto avviso che avvisa che l'applicazione non è affidabile in diversi casi e gli amministratori di Workspace possono persino impedire alle persone di accettare le applicazioni OAuth. +> 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** consente di creare applicazioni che possono **interagire per conto degli utenti** con diversi **servizi Google**: Gmail, Drive, GCP... +**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 all'interno di GCP** e indicare gli ambiti (permessi) di cui l'app ha bisogno per accedere ai dati degli utenti.\ -Quando un **utente** desidera **utilizzare** quell'**applicazione**, verrà **richiesto** di **accettare** che l'applicazione avrà accesso ai propri dati specificati negli ambiti. +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 allettante per **phishare** utenti non tecnici nell'utilizzo di **applicazioni che accedono a informazioni sensibili** perché potrebbero non comprendere le conseguenze. Tuttavia, negli account delle organizzazioni, ci sono modi per prevenire che ciò accada. +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. -### Avviso di App non verificate +### Unverified App prompt -Come è stato menzionato, Google presenterà sempre un **avviso all'utente per accettare** i permessi che stanno dando all'applicazione per conto loro. Tuttavia, se l'applicazione è considerata **pericolosa**, Google mostrerà **prima** un **avviso** che indica che è **pericolosa** e **rende più difficile** per l'utente concedere i permessi all'app. +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 avviso appare nelle app che: +Questo prompt appare in app che: -- Usano qualsiasi ambito che può accedere a dati privati (Gmail, Drive, GCP, BigQuery...) -- App con meno di 100 utenti (per app > 100 è necessario anche un processo di revisione per smettere di mostrare l'avviso di non verifica) +- 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) -### Ambiti Interessanti +### Interesting Scopes -[**Qui**](https://developers.google.com/identity/protocols/oauth2/scopes) puoi trovare un elenco di tutti gli ambiti OAuth di Google. +[**Here**](https://developers.google.com/identity/protocols/oauth2/scopes) you can find a list of all the Google OAuth scopes. -- **cloud-platform**: Visualizza e gestisci i tuoi dati attraverso i servizi di **Google Cloud Platform**. Puoi impersonare l'utente in GCP. -- **admin.directory.user.readonly**: Vedi e scarica la directory GSuite della tua organizzazione. Ottieni nomi, telefoni, URL del calendario di tutti gli utenti. +- **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. -### Crea un OAuth App +### Create an OAuth App -**Inizia a creare un OAuth Client ID** +**Start creating an OAuth Client ID** -1. Vai a [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) e clicca su configura la schermata di consenso. -2. Poi, ti verrà chiesto se il **tipo di utente** è **interno** (solo per le persone nella tua organizzazione) o **esterno**. Seleziona quello che si adatta alle tue esigenze -- Interno potrebbe essere interessante se hai già compromesso un utente dell'organizzazione e stai creando questa App per phishingare un altro. -3. Dai un **nome** all'app, un **email di supporto** (nota che puoi impostare un'email di googlegroup per cercare di anonimizzarti un po' di più), un **logo**, **domini autorizzati** e un'altra **email** per **aggiornamenti**. -4. **Seleziona** gli **ambiti OAuth**. -- Questa pagina è divisa in permessi non sensibili, permessi sensibili e permessi ristretti. Ogni volta che aggiungi un nuovo permesso, viene aggiunto alla sua categoria. A seconda dei permessi richiesti, appariranno diversi avvisi all'utente indicando quanto siano sensibili questi permessi. +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** potrebbe essere interessante se hai già compromesso un utente dell'organizzazione e stai creando questa App per phishare un altro. +3. 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**. +4. **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. -5. **Aggiungi gli utenti di test.** Finché lo stato dell'app è in fase di test, solo questi utenti potranno accedere all'app, quindi assicurati di **aggiungere l'email che stai per phishingare**. +5. **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 **credenziali per un'applicazione web** utilizzando il **precedentemente creato OAuth Client ID**: +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](https://console.cloud.google.com/apis/credentials/oauthclient), questa volta apparirà un'opzione diversa. -2. Seleziona di **creare credenziali per un'applicazione web** -3. Imposta i necessari **origini Javascript** e **URI di reindirizzamento** -- Puoi impostare in entrambi qualcosa come **`http://localhost:8000/callback`** per testare -4. Ottieni le **credenziali** della tua applicazione +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`** +4. Ottieni le **credentials** della tua applicazione -Infine, eseguiamo **un'applicazione web che utilizzerà le credenziali dell'applicazione OAuth**. Puoi trovare un esempio in [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example). +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](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-secret "" ``` -Vai su **`http://localhost:8000`**, clicca sul pulsante Accedi con Google, ti verrà **richiesto** un messaggio come questo: +Vai su **`http://localhost:8000`**, clicca sul pulsante Login with Google, ti verrà **mostrato** un messaggio come questo:
-L'applicazione mostrerà il **token di accesso e il token di aggiornamento** che possono essere facilmente utilizzati. Per ulteriori informazioni su **come utilizzare questi token controlla**: +L'applicazione mostrerà gli **access and refresh token** che possono essere facilmente utilizzati. Per maggiori informazioni su **how to use these tokens check**: {{#ref}} ../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md {{#endref}} -#### Utilizzando `glcoud` +#### Using `glcoud` -È possibile fare qualcosa utilizzando gcloud invece della console web, controlla: +È possibile fare alcune operazioni usando gcloud invece della console web, consulta: {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md {{#endref}} +#### 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. +```bash +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` +```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) +``` +**Risposta / contenimento:** + +- Revoca i token per l'OAuth client ID malevolo: +```bash +gam all users delete tokens clientId +``` +- 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 - [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 e Beau Bullock - OK Google, come faccio a Red Team GSuite? +- [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}}