From e8083eb236b3e2d510a164613d6f1289af0ede8e Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Wed, 26 Feb 2025 00:22:01 +0000
Subject: [PATCH] Translated
 ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting

---
 .../gcp-to-workspace-pivoting/README.md       | 32 +++++++++----------
 .../gws-google-platforms-phishing/README.md   | 20 ++++++------
 2 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md b/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
index f8f1854f0..37e546bc6 100644
--- a/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
+++ b/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
@@ -9,7 +9,7 @@
 A delegação em domínio do Google Workspace permite que um objeto de identidade, seja um **aplicativo externo** do Google Workspace Marketplace ou uma **Conta de Serviço GCP** interna, **acesse dados em todo o Workspace em nome dos usuários**.
 
 > [!NOTE]
-> Isso basicamente significa que **contas de serviço** dentro dos projetos GCP de uma organização podem ser capazes de **impersonar usuários do Workspace** da mesma organização (ou até mesmo de uma diferente).
+> Isso basicamente significa que **contas de serviço** dentro dos projetos GCP de uma organização podem ser capazes de **fingir ser usuários do Workspace** da mesma organização (ou até mesmo de uma diferente).
 
 Para mais informações sobre como isso funciona exatamente, consulte:
 
@@ -19,8 +19,8 @@ gcp-understanding-domain-wide-delegation.md
 
 ### Comprometendo a delegação existente
 
-Se um atacante **comprometeu algum acesso ao GCP** e **conhece um e-mail de usuário válido do Workspace** (preferencialmente **super admin**) da empresa, ele poderia **enumerar todos os projetos** aos quais tem acesso, **enumerar todas as SAs** dos projetos, verificar a quais **contas de serviço ele tem acesso** e **repetir** todas essas etapas com cada SA que pode impersonar.\
-Com uma **lista de todas as contas de serviço** às quais ele tem **acesso** e a lista de **e-mails do Workspace**, o atacante poderia tentar **impersonar o usuário com cada conta de serviço**.
+Se um atacante **comprometeu algum acesso ao GCP** e **conhece um e-mail de usuário válido do Workspace** (preferencialmente **super admin**) da empresa, ele poderia **enumerar todos os projetos** aos quais tem acesso, **enumerar todas as SAs** dos projetos, verificar a quais **contas de serviço ele tem acesso** e **repetir** todas essas etapas com cada SA que pode fingir.\
+Com uma **lista de todas as contas de serviço** às quais ele tem **acesso** e a lista de **e-mails do Workspace**, o atacante poderia tentar **fingir ser o usuário com cada conta de serviço**.
 
 > [!CAUTION]
 > Note que ao configurar a delegação em domínio, nenhum usuário do Workspace é necessário, portanto, apenas saber que **um válido é suficiente e necessário para a impersonação**.\
@@ -40,13 +40,13 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
 
 Esta é uma ferramenta que pode realizar o ataque seguindo estes passos:
 
-1. **Enumerar Projetos GCP** usando a API do Resource Manager.
+1. **Enumerar Projetos GCP** usando a API Resource Manager.
 2. Iterar sobre cada recurso do projeto e **enumerar recursos de conta de serviço GCP** aos quais o usuário IAM inicial tem acesso usando _GetIAMPolicy_.
-3. Iterar sobre **cada função de conta de serviço** e encontrar funções integradas, básicas e personalizadas com permissão _**serviceAccountKeys.create**_ no recurso da conta de serviço alvo. Deve-se notar que a função Editor possui essa permissão por padrão.
-4. Criar uma **nova chave privada `KEY_ALG_RSA_2048`** para cada recurso de conta de serviço que foi encontrado com permissão relevante na política IAM.
-5. Iterar sobre **cada nova conta de serviço e criar um `JWT`** **objeto** para ela, que é composto pelas credenciais da chave privada da SA e um escopo OAuth. O processo de criação de um novo objeto _JWT_ **iterará sobre todas as combinações existentes de escopos OAuth** da lista **oauth_scopes.txt**, a fim de encontrar todas as possibilidades de delegação. A lista **oauth_scopes.txt** é atualizada com todos os escopos OAuth que consideramos relevantes para abusar das identidades do Workspace.
-6. O método `_make_authorization_grant_assertion` revela a necessidade de declarar um **usuário de workspace alvo**, referido como _subject_, para gerar JWTs sob DWD. Embora isso possa parecer exigir um usuário específico, é importante perceber que **DWD influencia todas as identidades dentro de um domínio**. Consequentemente, criar um JWT para **qualquer usuário de domínio** afeta todas as identidades nesse domínio, consistente com nossa verificação de enumeração de combinações. Simplificando, um usuário válido do Workspace é suficiente para prosseguir.\
-Esse usuário pode ser definido no arquivo _config.yaml_ do DeleFriend. Se um usuário de workspace alvo não for conhecido, a ferramenta facilita a identificação automática de usuários de workspace válidos, escaneando usuários de domínio com funções em projetos GCP. É importante notar (novamente) que os JWTs são específicos do domínio e não são gerados para cada usuário; portanto, o processo automático visa uma única identidade única por domínio.
+3. Iterar sobre **cada função de conta de serviço** e encontrar funções integradas, básicas e personalizadas com permissão _**serviceAccountKeys.create**_ no recurso de conta de serviço alvo. Deve-se notar que a função Editor possui essa permissão por padrão.
+4. Criar uma **nova chave privada `KEY_ALG_RSA_2048`** para cada recurso de conta de serviço que for encontrado com a permissão relevante na política IAM.
+5. Iterar sobre **cada nova conta de serviço e criar um `JWT`** **objeto** para ela, que é composto pelas credenciais da chave privada da SA e um escopo OAuth. O processo de criação de um novo objeto _JWT_ irá **iterar sobre todas as combinações existentes de escopos OAuth** da lista **oauth_scopes.txt**, a fim de encontrar todas as possibilidades de delegação. A lista **oauth_scopes.txt** é atualizada com todos os escopos OAuth que consideramos relevantes para abusar das identidades do Workspace.
+6. O método `_make_authorization_grant_assertion` revela a necessidade de declarar um **usuário de workspace alvo**, referido como _subject_, para gerar JWTs sob DWD. Embora isso possa parecer exigir um usuário específico, é importante perceber que **DWD influencia toda identidade dentro de um domínio**. Consequentemente, criar um JWT para **qualquer usuário de domínio** afeta todas as identidades nesse domínio, consistente com nossa verificação de enumeração de combinações. Simplificando, um usuário válido do Workspace é suficiente para prosseguir.\
+Esse usuário pode ser definido no arquivo _config.yaml_ do DeleFriend. Se um usuário de workspace alvo não for conhecido, a ferramenta facilita a identificação automática de usuários válidos do workspace, escaneando usuários de domínio com funções em projetos GCP. É fundamental notar (novamente) que os JWTs são específicos do domínio e não gerados para cada usuário; portanto, o processo automático visa uma única identidade única por domínio.
 7. **Enumerar e criar um novo token de acesso bearer** para cada JWT e validar o token contra a API tokeninfo.
 
 #### [Script Python do Gitlab](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
@@ -77,9 +77,9 @@ pip install --upgrade --user oauth2client
 
 É possível **verificar Delegações de Domínio Amplo em** [**https://admin.google.com/u/1/ac/owl/domainwidedelegation**](https://admin.google.com/u/1/ac/owl/domainwidedelegation)**.**
 
-Um atacante com a capacidade de **criar contas de serviço em um projeto GCP** e **privilégios de super administrador no GWS pode criar uma nova delegação permitindo que SAs se façam passar por alguns usuários do GWS:**
+Um atacante com a capacidade de **criar contas de serviço em um projeto GCP** e **privilégios de super administrador no GWS poderia criar uma nova delegação permitindo que SAs impersonem alguns usuários do GWS:**
 
-1. **Gerando uma Nova Conta de Serviço e Par de Chaves Correspondente:** No GCP, novos recursos de conta de serviço podem ser produzidos interativamente via console ou programaticamente usando chamadas diretas de API e ferramentas de CLI. Isso requer o **papel `iam.serviceAccountAdmin`** ou qualquer papel personalizado equipado com a **permissão `iam.serviceAccounts.create`**. Uma vez que a conta de serviço é criada, procederemos a gerar um **par de chaves relacionado** (**permissão `iam.serviceAccountKeys.create`**).
+1. **Gerando uma Nova Conta de Serviço e Par de Chaves Correspondente:** No GCP, novos recursos de conta de serviço podem ser produzidos interativamente via console ou programaticamente usando chamadas diretas de API e ferramentas CLI. Isso requer o **papel `iam.serviceAccountAdmin`** ou qualquer papel personalizado equipado com a **permissão `iam.serviceAccounts.create`**. Uma vez que a conta de serviço é criada, procederemos a gerar um **par de chaves relacionado** (**permissão `iam.serviceAccountKeys.create`**).
 2. **Criação de nova delegação**: É importante entender que **apenas o papel de Super Admin possui a capacidade de configurar delegação global de Domínio Amplo no Google Workspace** e a delegação de Domínio Amplo **não pode ser configurada programaticamente,** ela pode ser criada e ajustada **manualmente** através do **console** do Google Workspace.
 - A criação da regra pode ser encontrada na página **Controles de API → Gerenciar delegação de Domínio Amplo no console de administração do Google Workspace**.
 3. **Anexando privilégios de escopos OAuth**: Ao configurar uma nova delegação, o Google requer apenas 2 parâmetros, o ID do Cliente, que é o **ID OAuth do recurso de Conta de Serviço do GCP**, e **escopos OAuth** que definem quais chamadas de API a delegação requer.
@@ -89,7 +89,7 @@ Um atacante com a capacidade de **criar contas de serviço em um projeto GCP** e
 
 #### Delegação Interorganizacional
 
-O ID SA OAuth é global e pode ser usado para **delegação interorganizacional**. Não houve restrições implementadas para impedir a delegação global cruzada. Em termos simples, **contas de serviço de diferentes organizações GCP podem ser usadas para configurar delegação de domínio amplo em outras organizações Workspace**. Isso resultaria em **apenas precisar de acesso de Super Admin ao Workspace**, e não acesso à mesma conta GCP, já que o adversário pode criar Contas de Serviço e chaves privadas em sua conta GCP pessoalmente controlada.
+O ID SA OAuth é global e pode ser usado para **delegação interorganizacional**. Não houve restrição implementada para impedir a delegação global cruzada. Em termos simples, **contas de serviço de diferentes organizações GCP podem ser usadas para configurar delegação de domínio amplo em outras organizações Workspace**. Isso resultaria em **apenas precisar de acesso de Super Admin ao Workspace**, e não acesso à mesma conta GCP, já que o adversário pode criar Contas de Serviço e chaves privadas em sua conta GCP pessoalmente controlada.
 
 ### Criando um Projeto para enumerar o Workspace
 
@@ -127,10 +127,10 @@ Verifique **mais enumeração em**:
 Você pode encontrar mais informações sobre o fluxo `gcloud` para login em:
 
 {{#ref}}
-../gcp-persistence/gcp-non-svc-persistance.md
+../gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
-Conforme explicado lá, o gcloud pode solicitar o escopo **`https://www.googleapis.com/auth/drive`** que permitiria a um usuário acessar o drive do usuário.\
+Como explicado lá, o gcloud pode solicitar o escopo **`https://www.googleapis.com/auth/drive`** que permitiria a um usuário acessar o drive do usuário.\
 Como um atacante, se você comprometeu **fisicamente** o computador de um usuário e o **usuário ainda está logado** com sua conta, você poderia fazer login gerando um token com acesso ao drive usando:
 ```bash
 gcloud auth login --enable-gdrive-access
@@ -148,9 +148,9 @@ Se um atacante comprometer o computador de um usuário, ele também poderá modi
 
 ### Acesso a usuários privilegiados do GCP
 
-Se um atacante tiver acesso completo ao GWS, ele poderá acessar grupos com acesso privilegiado ao GCP ou até mesmo usuários, portanto, mover-se de GWS para GCP é geralmente mais "simples" apenas porque **os usuários no GWS têm altos privilégios sobre o GCP**.
+Se um atacante tiver acesso completo ao GWS, ele poderá acessar grupos com acesso privilegiado ao GCP ou até mesmo usuários, portanto, mover-se do GWS para o GCP é geralmente mais "simples" apenas porque **os usuários no GWS têm altos privilégios sobre o GCP**.
 
-### Escalonamento de Privilégios do Google Groups
+### Escalada de Privilégios do Google Groups
 
 Por padrão, os usuários podem **entrar livremente em grupos do Workspace da Organização** e esses grupos **podem ter permissões do GCP** atribuídas (verifique seus grupos em [https://groups.google.com/](https://groups.google.com/)).
 
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 33332c75a..d9e0994cf 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
@@ -12,13 +12,13 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
 
 Aparentemente, por padrão, em workspace os membros [**podem criar grupos**](https://groups.google.com/all-groups) **e convidar pessoas para eles**. Você pode então modificar o e-mail que será enviado ao usuário **adicionando alguns links.** O **e-mail virá de um endereço google**, então parecerá **legítimo** e as pessoas podem clicar no link.
 
-Também é possível definir o endereço **FROM** como o **e-mail do grupo Google** para enviar **mais e-mails para os usuários dentro do grupo**, como na imagem a seguir onde o grupo **`google--support@googlegroups.com`** foi criado e um **e-mail foi enviado a todos os membros** do grupo (que foram adicionados sem qualquer consentimento)
+Também é possível definir o endereço **FROM** como o **e-mail do grupo Google** para enviar **mais e-mails para os usuários dentro do grupo**, como na imagem a seguir, onde o grupo **`google--support@googlegroups.com`** foi criado e um **e-mail foi enviado a todos os membros** do grupo (que foram adicionados sem qualquer consentimento)
 
 <figure><img src="../../../images/image (5) (1).png" alt=""><figcaption></figcaption></figure>
 
 ## Google Chat Phishing
 
-Você pode ser capaz de **iniciar um chat** com uma pessoa apenas tendo seu endereço de e-mail ou enviar um **convite para conversar**. Além disso, é possível **criar um Espaço** que pode ter qualquer nome (por exemplo, "Suporte Google") e **convidar** membros para isso. Se eles aceitarem, podem pensar que estão conversando com o Suporte Google:
+Você pode ser capaz de **iniciar um chat** com uma pessoa apenas tendo seu endereço de e-mail ou enviar um **convite para conversar**. Além disso, é possível **criar um Espaço** que pode ter qualquer nome (por exemplo, "Suporte Google") e **convidar** membros para ele. Se eles aceitarem, podem pensar que estão conversando com o Suporte Google:
 
 <figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
 
@@ -69,9 +69,9 @@ Por exemplo, acessando [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G3
 > [!TIP]
 > Note que um aviso aparecerá enquanto o conteúdo é carregado dentro de um iframe.
 
-## Phishing de OAuth em App Scripts
+## Phishing de OAuth de App Scripts
 
-É possível criar App Scripts anexados a documentos para tentar obter acesso ao token OAuth de uma vítima, para mais informações, consulte:
+É possível criar App Scripts anexados a documentos para tentar obter acesso ao token OAuth de uma vítima, para mais informações consulte:
 
 {{#ref}}
 gws-app-scripts.md
@@ -91,9 +91,9 @@ Quando um **usuário** deseja **usar** essa **aplicação**, ele será **solicit
 
 Esta é uma maneira muito atraente de **phish** usuários não técnicos para usar **aplicações que acessam informações sensíveis** porque eles podem não entender as consequências. No entanto, em contas de organizações, existem maneiras de evitar que isso aconteça.
 
-### Aviso de Aplicativo Não Verificado
+### Aviso de App Não Verificado
 
-Como foi mencionado, o Google sempre apresentará um **aviso ao usuário para aceitar** as permissões que estão concedendo à aplicação em seu nome. No entanto, se a aplicação for considerada **perigosa**, o Google mostrará **primeiro** um **aviso** indicando que é **perigosa** e **dificultando** para o usuário conceder as permissões ao app.
+Como foi mencionado, o Google sempre apresentará um **aviso ao usuário para aceitar** as permissões que estão concedendo à aplicação em seu nome. No entanto, se a aplicação for considerada **perigosa**, o Google mostrará **primeiro** um **aviso** indicando que é **perigosa** e **dificultando mais** para o usuário conceder as permissões ao app.
 
 Esse aviso aparece em apps que:
 
@@ -118,14 +118,14 @@ Esse aviso aparece em apps que:
 4. **Selecione** os **escopos OAuth**.
 - Esta página é dividida em permissões não sensíveis, permissões sensíveis e permissões restritas. Sempre que você adicionar uma nova permissão, ela é adicionada em sua categoria. Dependendo das permissões solicitadas, diferentes avisos aparecerão para o usuário indicando quão sensíveis essas permissões são.
 - Tanto **`admin.directory.user.readonly`** quanto **`cloud-platform`** são permissões sensíveis.
-5. **Adicione os usuários de teste.** Enquanto o status do app for de teste, apenas esses usuários poderão acessar o app, então certifique-se de **adicionar o e-mail que você vai phish**.
+5. **Adicione os usuários de teste.** Enquanto o status do app for teste, apenas esses usuários poderão acessar o app, então certifique-se de **adicionar o e-mail que você vai phish**.
 
 Agora vamos obter **credenciais para uma aplicação web** usando o **ID de Cliente OAuth criado anteriormente**:
 
 1. Volte para [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), uma opção diferente aparecerá desta vez.
-2. Selecione **criar credenciais para uma aplicação web**
+2. Selecione **criar credenciais para uma aplicação Web**
 3. Defina os **origens Javascript** e **URIs de redirecionamento** necessários
-- Você pode definir em ambos algo como **`http://localhost:8000/callback`** para testes
+- Você pode definir em ambos algo como **`http://localhost:8000/callback`** para teste
 4. Obtenha suas **credenciais da aplicação**
 
 Finalmente, vamos **executar uma aplicação web que usará as credenciais da aplicação OAuth**. Você pode encontrar um exemplo em [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
@@ -142,7 +142,7 @@ Vá para **`http://localhost:8000`**, clique no botão Login with Google, você
 O aplicativo mostrará o **token de acesso e o token de atualização** que podem ser facilmente usados. Para mais informações sobre **como usar esses tokens, verifique**:
 
 {{#ref}}
-../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
+../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
 #### Usando `glcoud`