Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting

src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md

@@ -9,7 +9,7 @@
 La delega a livello di dominio di Google Workspace consente a un oggetto identità, sia un **app esterna** dal Google Workspace Marketplace che un **Account di Servizio GCP** interno, di **accedere ai dati attraverso il Workspace per conto degli utenti**.
 
 > [!NOTE]
-> Questo significa fondamentalmente che gli **account di servizio** all'interno dei progetti GCP di un'organizzazione potrebbero essere in grado di **impersonare gli utenti di Workspace** della stessa organizzazione (o anche di un'altra).
+> Questo significa fondamentalmente che gli **account di servizio** all'interno dei progetti GCP di un'organizzazione potrebbero essere in grado di **impostare l'identità degli utenti di Workspace** della stessa organizzazione (o anche di un'altra).
 
 Per ulteriori informazioni su come funziona esattamente, controlla:
 
@@ -20,10 +20,10 @@ gcp-understanding-domain-wide-delegation.md
 ### Compromettere la delega esistente
 
 Se un attaccante **ha compromesso alcuni accessi su GCP** e **conosce un'email valida di un utente di Workspace** (preferibilmente **super admin**) dell'azienda, potrebbe **enumerare tutti i progetti** a cui ha accesso, **enumerare tutti gli SA** dei progetti, controllare a quali **account di servizio ha accesso** e **ripetere** tutti questi passaggi con ciascun SA che può impersonare.\
-Con un **elenco di tutti gli account di servizio** a cui ha **accesso** e l'elenco delle **email di Workspace**, l'attaccante potrebbe provare a **impersonare l'utente con ciascun account di servizio**.
+Con un **elenco di tutti gli account di servizio** a cui ha **accesso** e l'elenco delle **email di Workspace**, l'attaccante potrebbe provare a **impostare l'identità dell'utente con ciascun account di servizio**.
 
 > [!CAUTION]
-> Nota che quando si configura la delega a livello di dominio non è necessario alcun utente di Workspace, quindi basta sapere che **uno valido è sufficiente e richiesto per l'impersonificazione**.\
+> Nota che quando si configura la delega a livello di dominio non è necessario alcun utente di Workspace, quindi basta sapere che **uno valido è sufficiente e richiesto per l'impostazione dell'identità**.\
 > Tuttavia, i **privilegi dell'utente impersonato saranno utilizzati**, quindi se è Super Admin potrai accedere a tutto. Se non ha alcun accesso, questo sarà inutile.
 
 #### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
@@ -42,11 +42,11 @@ Questo è uno strumento che può eseguire l'attacco seguendo questi passaggi:
 
 1. **Enumerare i progetti GCP** utilizzando l'API Resource Manager.
 2. Iterare su ciascuna risorsa del progetto e **enumerare le risorse dell'account di servizio GCP** a cui l'utente IAM iniziale ha accesso utilizzando _GetIAMPolicy_.
-3. Iterare su **ogni ruolo dell'account di servizio** e trovare ruoli incorporati, di base e personalizzati con il permesso _**serviceAccountKeys.create**_ sulla risorsa dell'account di servizio target. Va notato che il ruolo di Editor possiede intrinsecamente questo permesso.
-4. Creare una **nuova chiave privata `KEY_ALG_RSA_2048`** per ciascuna risorsa dell'account di servizio trovata con il permesso rilevante nella policy IAM.
-5. Iterare su **ogni nuovo account di servizio e creare un oggetto `JWT`** per esso composto dalle credenziali della chiave privata SA e da un ambito OAuth. Il processo di creazione di un nuovo oggetto _JWT_ **itererà su tutte le combinazioni esistenti di ambiti OAuth** dalla lista **oauth_scopes.txt**, al fine di trovare tutte le possibilità di delega. La lista **oauth_scopes.txt** è aggiornata con tutti gli ambiti OAuth che abbiamo trovato rilevanti per abusare delle identità di Workspace.
-6. Il metodo `_make_authorization_grant_assertion` rivela la necessità di dichiarare un **utente workspace target**, riferito come _subject_, per generare JWT sotto DWD. Anche se questo può sembrare richiedere un utente specifico, è importante rendersi conto che **DWD influisce su ogni identità all'interno di un dominio**. Di conseguenza, creare un JWT per **qualsiasi utente di dominio** influisce su tutte le identità in quel dominio, coerente con il nostro controllo di enumerazione delle combinazioni. In parole semplici, un utente Workspace valido è sufficiente per procedere.\
-Questo utente può essere definito nel file _config.yaml_ di DeleFriend. Se un utente workspace target non è già noto, lo strumento facilita l'identificazione automatica di utenti workspace validi scansionando gli utenti di dominio con ruoli sui progetti GCP. È fondamentale notare (di nuovo) che i JWT sono specifici per il dominio e non generati per ogni utente; pertanto, il processo automatico mira a un'unica identità unica per dominio.
+3. Iterare su **ogni ruolo dell'account di servizio** e trovare ruoli predefiniti, di base e personalizzati con il permesso _**serviceAccountKeys.create**_ sulla risorsa dell'account di servizio target. Va notato che il ruolo di Editor possiede intrinsecamente questo permesso.
+4. Creare una **nuova chiave privata `KEY_ALG_RSA_2048`** per ciascuna risorsa dell'account di servizio che è stata trovata con il permesso rilevante nella policy IAM.
+5. Iterare su **ogni nuovo account di servizio e creare un oggetto `JWT`** per esso, composto dalle credenziali della chiave privata SA e da un ambito OAuth. Il processo di creazione di un nuovo oggetto _JWT_ **itererà su tutte le combinazioni esistenti di ambiti OAuth** dalla lista **oauth_scopes.txt**, al fine di trovare tutte le possibilità di delega. La lista **oauth_scopes.txt** è aggiornata con tutti gli ambiti OAuth che abbiamo trovato rilevanti per abusare delle identità di Workspace.
+6. Il metodo `_make_authorization_grant_assertion` rivela la necessità di dichiarare un **utente workspace target**, riferito come _subject_, per generare JWT sotto DWD. Anche se questo può sembrare richiedere un utente specifico, è importante rendersi conto che **DWD influisce su ogni identità all'interno di un dominio**. Di conseguenza, creare un JWT per **qualsiasi utente di dominio** influisce su tutte le identità in quel dominio, in linea con il nostro controllo di enumerazione delle combinazioni. In parole semplici, un utente Workspace valido è sufficiente per procedere.\
+Questo utente può essere definito nel file _config.yaml_ di DeleFriend. Se un utente workspace target non è già noto, lo strumento facilita l'identificazione automatica di utenti workspace validi scansionando gli utenti di dominio con ruoli sui progetti GCP. È fondamentale notare (ancora) che i JWT sono specifici per il dominio e non vengono generati per ogni utente; pertanto, il processo automatico mira a un'unica identità unica per dominio.
 7. **Enumerare e creare un nuovo token di accesso bearer** per ciascun JWT e convalidare il token contro l'API tokeninfo.
 
 #### [Script Python di Gitlab](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
@@ -77,7 +77,7 @@ pip install --upgrade --user oauth2client
 
 È possibile **controllare le deleghe a livello di dominio in** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**
 
-Un attaccante con la capacità di **creare account di servizio in un progetto GCP** e **privilegi di super amministratore su GWS potrebbe creare una nuova delega che consente agli SAs di impersonare alcuni utenti GWS:**
+Un attaccante con la capacità di **creare account di servizio in un progetto GCP** e **privilegi di super amministratore su GWS potrebbe creare una nuova delega che consente agli SA di impersonare alcuni utenti GWS:**
 
 1. **Generazione di un nuovo account di servizio e del relativo paio di chiavi:** Su GCP, le nuove risorse di account di servizio possono essere prodotte sia interattivamente tramite la console che programmaticamente utilizzando chiamate API dirette e strumenti CLI. Questo richiede il **ruolo `iam.serviceAccountAdmin`** o qualsiasi ruolo personalizzato dotato del **permesso `iam.serviceAccounts.create`**. Una volta creato l'account di servizio, procederemo a generare un **paio di chiavi correlate** (**permesso `iam.serviceAccountKeys.create`**).
 2. **Creazione di una nuova delega**: È importante comprendere che **solo il ruolo di Super Admin ha la capacità di impostare la delega globale a livello di dominio in Google Workspace** e la delega a livello di dominio **non può essere impostata programmaticamente,** può essere creata e regolata **manualmente** tramite la **console** di Google Workspace.
@@ -85,20 +85,20 @@ Un attaccante con la capacità di **creare account di servizio in un progetto GC
 3. **Attaccare i privilegi degli ambiti OAuth**: Quando si configura una nuova delega, Google richiede solo 2 parametri, l'ID client, che è l'**ID OAuth della risorsa dell'account di servizio GCP**, e **ambiti OAuth** che definiscono quali chiamate API richiede la delega.
 - L'**elenco completo degli ambiti OAuth** può essere trovato [**qui**](https://developers.google.com/identity/protocols/oauth2/scopes), ma qui c'è una raccomandazione: `https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid`
 4. **Agire per conto dell'identità target:** A questo punto, abbiamo un oggetto delegato funzionante in GWS. Ora, **utilizzando la chiave privata dell'account di servizio GCP, possiamo eseguire chiamate API** (nell'ambito definito nel parametro dell'ambito OAuth) per attivarlo e **agire per conto di qualsiasi identità esistente in Google Workspace**. Come abbiamo appreso, l'account di servizio genererà token di accesso secondo le proprie necessità e in base ai permessi che ha per le applicazioni REST API.
-- Controlla la **sezione precedente** per alcuni **strumenti** per utilizzare questa delega.
+- Controlla la **sezione precedente** per alcuni **strumenti** da utilizzare con questa delega.
 
 #### Delega inter-organizzativa
 
-L'ID SA OAuth è globale e può essere utilizzato per **delega inter-organizzativa**. Non è stata implementata alcuna restrizione per prevenire la delega globale incrociata. In termini semplici, **gli account di servizio di diverse organizzazioni GCP possono essere utilizzati per configurare la delega a livello di dominio su altre organizzazioni Workspace**. Questo comporterebbe **la necessità di avere solo accesso da Super Admin a Workspace**, e non accesso allo stesso account GCP, poiché l'avversario può creare account di servizio e chiavi private sul proprio account GCP controllato personalmente.
+L'ID SA OAuth è globale e può essere utilizzato per **delega inter-organizzativa**. Non è stata implementata alcuna restrizione per prevenire la delega interglobale. In termini semplici, **gli account di servizio di diverse organizzazioni GCP possono essere utilizzati per configurare la delega a livello di dominio su altre organizzazioni Workspace**. Questo comporterebbe **la necessità di avere solo accesso da Super Admin a Workspace**, e non accesso allo stesso account GCP, poiché l'avversario può creare account di servizio e chiavi private sul proprio account GCP controllato personalmente.
 
 ### Creazione di un progetto per enumerare Workspace
 
-Per **definizione** gli **utenti** di Workspace hanno il permesso di **creare nuovi progetti**, e quando viene creato un nuovo progetto, il **creatore ottiene il ruolo di Proprietario** su di esso.
+Per **definizione**, gli **utenti** di Workspace hanno il permesso di **creare nuovi progetti**, e quando viene creato un nuovo progetto, il **creatore ottiene il ruolo di Proprietario** su di esso.
 
 Pertanto, un utente può **creare un progetto**, **abilitare** le **API** per enumerare Workspace nel suo nuovo progetto e provare a **enumerarlo**.
 
 > [!CAUTION]
-> Affinché un utente possa enumerare Workspace, ha anche bisogno di permessi sufficienti su Workspace (non tutti gli utenti saranno in grado di enumerare la directory).
+> Affinché un utente possa enumerare Workspace, ha anche bisogno di sufficienti permessi di Workspace (non tutti gli utenti saranno in grado di enumerare la directory).
 ```bash
 # Create project
 gcloud projects create <uniq-projec-name> --name=proj-name
@@ -127,7 +127,7 @@ Controlla **ulteriore enumerazione in**:
 Puoi trovare ulteriori informazioni sul flusso `gcloud` per effettuare il login in:
 
 {{#ref}}
-../gcp-persistence/gcp-non-svc-persistance.md
+../gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
 Come spiegato lì, gcloud può richiedere l'ambito **`https://www.googleapis.com/auth/drive`** che consentirebbe a un utente di accedere al drive dell'utente.\
@@ -146,9 +146,9 @@ Se un attaccante compromette il computer di un utente, potrebbe anche modificare
 
 ## Da GWS a GCP
 
-### Accesso a utenti privilegiati GCP
+### Accesso a utenti privilegiati di GCP
 
-Se un attaccante ha accesso completo su GWS, sarà in grado di accedere a gruppi con accesso privilegiato su GCP o anche a utenti, quindi passare da GWS a GCP è solitamente più "semplice" solo perché **gli utenti in GWS hanno alti privilegi su GCP**.
+Se un attaccante ha accesso completo a GWS, sarà in grado di accedere a gruppi con accesso privilegiato su GCP o anche a utenti, quindi passare da GWS a GCP è solitamente più "semplice" solo perché **gli utenti in GWS hanno alti privilegi su GCP**.
 
 ### Escalation dei privilegi di Google Groups
 

src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md

@@ -10,7 +10,7 @@ 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à da un indirizzo google**, quindi sembrerà **legittima** e le persone potrebbero cliccare sul link.
+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.
 
 È 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)
 
@@ -18,7 +18,7 @@ A quanto pare, per impostazione predefinita, nei workspace i membri [**possono c
 
 ## Google Chat Phishing
 
-Potresti essere in grado di **iniziare una chat** con una persona avendo solo 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 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:
 
 <figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
 
@@ -29,8 +29,8 @@ Puoi controllare come questo ha funzionato in passato in: [https://www.youtube.c
 
 ## Google Doc Phishing
 
-In passato era possibile creare un **documento apparentemente legittimo** e in un commento **menzionare qualche email (come @user@gmail.com)**. Google **inviava un'email a quell'indirizzo email** notificando che erano stati menzionati nel documento.\
-Oggigiorno, questo non funziona, ma se **dai accesso al documento all'email della 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 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:
 
 <figure><img src="../../../images/image (7).png" alt=""><figcaption></figcaption></figure>
 
@@ -39,7 +39,7 @@ Oggigiorno, questo non funziona, ma se **dai accesso al documento all'email dell
 
 ## Google Calendar Phishing
 
-Puoi **creare un evento nel calendario** e aggiungere quanti più indirizzi email dell'azienda che stai attaccando. Pianifica questo evento nel calendario tra **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 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**).
 
 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).
 
@@ -79,10 +79,10 @@ 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 alto privilegio).
+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).
 
 > [!NOTE]
-> Nota che Google presenta un avviso poco attraente 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 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.
 
 **Google** consente di creare applicazioni che possono **interagire per conto degli utenti** con diversi **servizi Google**: Gmail, Drive, GCP...
 
@@ -93,12 +93,12 @@ Questo è un modo molto allettante per **phishare** utenti non tecnici nell'util
 
 ### Avviso di App non verificate
 
-Come è stato menzionato, Google presenterà sempre un **avviso all'utente per accettare** i permessi che stanno dando all'applicazione per loro conto. 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 è 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.
 
 Questo avviso appare nelle app che:
 
 - Usano qualsiasi ambito che può accedere a dati privati (Gmail, Drive, GCP, BigQuery...)
-- App con meno di 100 utenti (app > 100 è necessario anche un processo di revisione per smettere di mostrare l'avviso di non verifica)
+- App con meno di 100 utenti (per app > 100 è necessario anche un processo di revisione per smettere di mostrare l'avviso di non verifica)
 
 ### Ambiti Interessanti
 
@@ -112,11 +112,11 @@ Questo avviso appare nelle app che:
 **Inizia a creare un 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 soddisfa le tue esigenze
+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 che indicano quanto siano sensibili questi permessi.
+- 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.
 - 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**.
 
@@ -142,7 +142,7 @@ Vai su **`http://localhost:8000`**, clicca sul pulsante Accedi con Google, ti ve
 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**:
 
 {{#ref}}
-../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
+../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
 #### Utilizzando `glcoud`