From aba809a60b11fd4d67cd3caeb5c47645aa57434e Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 17 Mar 2026 18:57:36 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement --- .../az-exchange-hybrid-impersonation.md | 34 ++-- .../gws-google-platforms-phishing/README.md | 174 ++++++++++++------ 2 files changed, 133 insertions(+), 75 deletions(-) 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 045dddb04..1ad3edc3f 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 @@ ## Informações Básicas -Em designs legados de Exchange Hybrid, a implantação on-prem do Exchange podia autenticar-se como a mesma identidade de aplicação Entra usada pelo Exchange Online. Se um atacante comprometesse o servidor Exchange, extraísse a chave privada do certificado híbrido e realizasse um fluxo OAuth client-credentials, ele poderia obter tokens first-party com contexto de privilégio do Exchange Online. +Em designs legados do Exchange Hybrid, a implantação on-prem do Exchange podia autenticar-se como a mesma identidade de aplicação Entra usada pelo Exchange Online. Se um atacante comprometesse o servidor Exchange, extraísse a chave privada do certificado híbrido e realizasse um fluxo OAuth client-credentials, ele podia obter tokens first-party com contexto de privilégios do Exchange Online. -O risco prático não se limitava ao acesso a caixas de correio. Como o Exchange Online tinha amplas relações de confiança back-end, essa identidade podia interagir com serviços adicionais do Microsoft 365 e, em comportamentos antigos, podia ser aproveitada para um comprometimento mais profundo do tenant. +O risco prático não se limitava ao acesso a caixas de correio. Como o Exchange Online tinha amplas relações de confiança back-end, essa identidade podia interagir com serviços adicionais do Microsoft 365 e, em comportamentos antigos, podia ser usada para comprometer mais profundamente o tenant. ## Caminhos de Ataque e Fluxo Técnico -### Modify Federation Configuration via Exchange +### Modificar a Configuração de Federação via Exchange -Historicamente, os tokens do Exchange tinham permissões para gravar configurações de domínio/federação. Do ponto de vista do atacante, isso permitia a manipulação direta dos dados de confiança de domínios federados, incluindo listas de certificados de assinatura de token e flags de configuração que controlavam a aceitação de claims de MFA da infraestrutura de federação on-prem. +Historicamente, tokens do Exchange tinham permissões para gravar configurações de domínio/federação. Do ponto de vista do atacante, isso permitia manipular diretamente dados de confiança de domínios federados, incluindo listas de certificados de assinatura de token e flags de configuração que controlavam a aceitação de claims de MFA da infraestrutura de federação on-prem. -Isso significa que um servidor Exchange Hybrid comprometido podia ser usado para montar ou reforçar uma impersonação ao estilo ADFS mudando a configuração de federação a partir do lado cloud, mesmo quando o atacante começava apenas com o comprometimento do Exchange on-prem. +Isso significa que um servidor Exchange Hybrid comprometido podia ser usado para montar ou reforçar impersonation no estilo ADFS ao alterar a configuração de federação pelo lado da cloud, mesmo quando o atacante começava apenas a partir do compromisso on-prem do Exchange. -### ACS Actor Tokens and Service-to-Service Impersonation +### ACS Actor Tokens e Impersonação entre Serviços -Exchange's hybrid auth path used Access Control Service (ACS) actor tokens with `trustedfordelegation=true`. Those actor tokens were then embedded into a second, unsigned service token that carried the target user identity in an attacker-controlled section. Because the outer token was unsigned and the actor token delegated broadly, the caller could swap target users without re-authenticating. +O caminho de autenticação híbrido do Exchange usava Access Control Service (ACS) actor tokens com `trustedfordelegation=true`. Esses actor tokens eram então embutidos em um segundo service token não assinado que carregava a identidade do usuário alvo em uma seção controlada pelo atacante. Como o token externo era não assinado e o actor token delegava amplamente, o chamador podia trocar usuários alvo sem reautenticar. -Na prática, uma vez obtido o actor token, o atacante dispunha de um primitivo de impersonação de longa duração (tipicamente cerca de 24 horas) que era difícil de revogar no meio do seu período de validade. Isso permitia impersonação de usuários através das APIs do Exchange Online e SharePoint/OneDrive, incluindo exfiltração de dados de alto valor. +Na prática, uma vez obtido o actor token, o atacante tinha um primitivo de impersonação de longa duração (tipicamente cerca de 24 horas) que era difícil de revogar no meio do seu tempo de vida. Isso permitia impersonação de usuários através das APIs do Exchange Online e SharePoint/OneDrive, incluindo exfiltração de dados de alto valor. -Historicamente, o mesmo padrão também funcionava contra `graph.windows.net` ao construir um token de impersonação com o valor `netId` da vítima. Isso fornecia ação administrativa Entra direta como usuários arbitrários e possibilitava fluxos de takeover completo do tenant (por exemplo, criando uma nova conta Global Administrator). +Historicamente, o mesmo padrão também funcionava contra `graph.windows.net` ao construir um token de impersonation com o valor `netId` da vítima. Isso fornecia ação administrativa direta em Entra como usuários arbitrários e permitia workflows de takeover completo do tenant (por exemplo, criar uma nova conta Global Administrator). -## O que Não Funciona Mais +## O Que Não Funciona Mais -O caminho de impersonação via `graph.windows.net` por meio dos actor tokens do Exchange Hybrid foi corrigido. A antiga cadeia "Exchange to arbitrary Entra admin over Graph" deve ser considerada removida para essa rota específica de token. +O caminho de impersonation via `graph.windows.net` através de actor tokens do Exchange foi corrigido. A antiga cadeia "Exchange para administrador Entra arbitrário via Graph" deve ser considerada removida para essa rota específica de token. -Esta é a correção mais importante ao documentar o ataque: mantenha o risco de impersonação Exchange/SharePoint separado da escalada de impersonação no Graph que já foi corrigida. +Esta é a correção mais importante ao documentar o ataque: mantenha o risco de impersonation Exchange/SharePoint separado da escalada de impersonation via Graph que já foi corrigida. -## O que Ainda Pode Importar na Prática +## O Que Ainda Pode Importar na Prática -Se uma organização ainda executa uma configuração hybrid antiga ou incompleta com trust compartilhado e material de certificado exposto, o impacto da impersonação Exchange/SharePoint pode continuar severo. O ângulo de abuso da configuração de federação também pode permanecer relevante dependendo da configuração do tenant e do estado de migração. +Se uma organização ainda opera uma configuração híbrida antiga ou incompleta com confiança compartilhada e material de certificado exposto, o impacto de impersonation Exchange/SharePoint pode continuar severo. O ângulo de abuso da configuração de federação também pode permanecer relevante dependendo da configuração do tenant e do estado da migração. -A mitigação de longo prazo da Microsoft é separar as identidades on-prem e do Exchange Online para que o caminho de confiança de service principal compartilhado deixe de existir. Ambientes que completaram essa migração reduzem materialmente essa superfície de ataque. +A mitigação de longo prazo da Microsoft é separar as identidades on-prem e do Exchange Online para que o caminho de confiança do shared-service-principal deixe de existir. Ambientes que concluíram essa migração reduzem materialmente essa superfície de ataque. ## Notas de Detecção -Quando essa técnica é abusada, eventos de auditoria podem mostrar discrepâncias de identidade onde o user principal name corresponde a um usuário impersonado enquanto o contexto de display/fonte aponta para atividade do Exchange Online. Esse padrão de identidade mista é um sinal de caça de alto valor, embora defensores devam criar baseline dos fluxos de trabalho legítimos de administrador do Exchange para reduzir falsos positivos. +Quando essa técnica é abusada, eventos de auditoria podem mostrar discrepâncias de identidade onde o user principal name corresponde a um usuário impersonado enquanto o contexto de display/origem aponta para atividade do Exchange Online. Esse padrão de identidade mista é um sinal de hunting de alto valor, embora os defensores devam estabelecer uma baseline dos fluxos de trabalho legítimos de administradores do Exchange para reduzir falsos positivos. ## Referências -- 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 d9e0994cf..4fd12fb2f 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 Genérica de 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 -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. +Aparentemente, por padrão, membros do workspace [**podem criar grupos**](https://groups.google.com/all-groups) **e convidar pessoas para eles**. Você pode então modificar o email que será enviado ao usuário **adicionando alguns links.** O **email virá de um endereço google**, então parecerá **legit** 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 **email do Google group** para enviar **mais emails para os usuários dentro do grupo**, como na imagem abaixo onde o grupo **`google--support@googlegroups.com`** foi criado e um **email foi enviado para todos os membros** do grupo (que foram adicionados sem qualquer consentimento)
## 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 ele. 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 o email dela ou enviar um **convite para conversar**. Além disso, é possível **criar um Space** que pode ter qualquer nome (ex.: "Google Support") e **convidar** membros para ele. Se aceitarem, podem pensar que estão falando com o Google Support:
> [!TIP] -> **Nos meus testes, no entanto, os membros convidados nem sequer receberam um convite.** +> **Nos meus testes, no entanto, os membros convidados nem chegaram a receber um convite.** -Você pode verificar como isso funcionou no passado em: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s) +Você pode ver como isso funcionou no passado em: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s) ## Google Doc Phishing -No passado, era possível criar um **documento aparentemente legítimo** e em um comentário **mencionar algum e-mail (como @user@gmail.com)**. O Google **enviou um e-mail para esse endereço de e-mail** notificando que eles foram mencionados no documento.\ -Hoje em dia, isso não funciona, mas se você **der ao e-mail da vítima acesso ao documento**, o Google enviará um e-mail indicando isso. Esta é a mensagem que aparece quando você menciona alguém: +No passado era possível criar um **documento aparentemente legítimo** e então, em um comentário, **mencionar algum email (como @user@gmail.com)**. Google **enviava um email para esse endereço** notificando que haviam sido mencionados no documento.\ +Hoje em dia isso não funciona, mas se você **der à vítima acesso por email ao documento** o Google enviará um email indicando isso. Esta é a mensagem que aparece quando você menciona alguém:
> [!TIP] -> As vítimas podem ter mecanismos de proteção que não permitem que e-mails indicando que um documento externo foi compartilhado com elas cheguem ao seu e-mail. +> As vítimas podem ter mecanismos de proteção que impedem que emails indicando que um documento externo foi compartilhado com elas cheguem na caixa de entrada. ## Google Calendar Phishing -Você pode **criar um evento de calendário** e adicionar quantos endereços de e-mail da empresa que você está atacando tiver. Programe este evento de calendário em **5 ou 15 min** a partir do horário atual. Faça o evento parecer legítimo e **coloque um comentário e um título indicando que eles precisam ler algo** (com o **link de phishing**). +Você pode **criar um evento de calendário** e adicionar quantos endereços de email da empresa que você está atacando tiver. Agende esse evento de calendário para **5 ou 15 min** a partir do horário atual. Faça o evento parecer legítimo e **coloque um comentário e um título indicando que eles precisam ler algo** (com o **phishing link**). -Este é o alerta que aparecerá no navegador com um título de reunião "Demissão de Pessoas", então você poderia definir um título mais parecido com phishing (e até mesmo mudar o nome associado ao seu e-mail). +Este é o alerta que aparecerá no navegador com um título de reunião "Firing People", então você poderia definir um título mais convincente (e até alterar o nome associado ao seu email).
-Para parecer menos suspeito: +Para deixá-lo menos suspeito: -- Configure para que **os destinatários não possam ver as outras pessoas convidadas** -- **NÃO envie e-mails notificando sobre o evento**. Assim, as pessoas verão apenas seu aviso sobre uma reunião em 5 minutos e que precisam ler aquele link. -- Aparentemente, usando a API, você pode definir como **True** que **as pessoas** aceitaram **o evento** e até mesmo criar **comentários em nome delas**. +- Configure para que **os recebentes não possam ver as outras pessoas convidadas** +- NÃO envie emails notificando sobre o evento. Assim, as pessoas só verão o aviso sobre a reunião em 5mins e que precisam ler aquele link. +- Aparentemente, usando a API você pode definir como **True** que as **pessoas** **aceitaram** o evento e até criar **comentários em nome delas**. ## App Scripts Redirect Phishing -É possível criar um script em [https://script.google.com/](https://script.google.com/) e **expor como uma aplicação web acessível por todos** que usará o domínio legítimo **`script.google.com`**.\ -Com algum código como o seguinte, um atacante poderia fazer o script carregar conteúdo arbitrário nesta página sem parar de acessar o domínio: +É possível criar um script em [https://script.google.com/](https://script.google.com/) e **expor ele como uma aplicação web acessível por todos** que usará o domínio legítimo **`script.google.com`**.\ +Com algum código como o seguinte um atacante poderia fazer o script carregar conteúdo arbitrário nesta página sem parar de acessar o domínio: ```javascript function doGet() { return HtmlService.createHtmlOutput( @@ -62,84 +62,83 @@ return HtmlService.createHtmlOutput( ).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL) } ``` -Por exemplo, acessando [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) você verá: +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] -> Note que um aviso aparecerá enquanto o conteúdo é carregado dentro de um iframe. +> Observe que um aviso aparecerá, pois o conteúdo é carregado dentro de um iframe. -## Phishing de OAuth de App Scripts +## App Scripts OAuth Phishing -É 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, veja: {{#ref}} gws-app-scripts.md {{#endref}} -## Phishing de Apps OAuth +## OAuth Apps Phishing -Qualquer uma das técnicas anteriores pode ser usada para fazer o usuário acessar uma **aplicação Google OAuth** que **solicitará** ao usuário algum **acesso**. Se o usuário **confiar** na **fonte**, ele pode **confiar** na **aplicação** (mesmo que esteja pedindo permissões de alto privilégio). +Qualquer uma das técnicas anteriores pode ser usada para fazer o usuário acessar uma **Google OAuth application** que irá **solicitar** ao usuário algum **acesso**. Se o usuário **confia** na **fonte**, ele pode **confiar** na **aplicação** (mesmo que ela esteja pedindo permissões de alto privilégio). > [!NOTE] -> Note que o Google apresenta um aviso feio informando que a aplicação é não confiável em vários casos e os administradores do Workspace podem até impedir que as pessoas aceitem aplicações OAuth. +> Observe que o Google apresenta um prompt pouco amigável avisando que a aplicação não é confiável em vários casos, e os admins do Workspace podem até impedir que as pessoas aceitem OAuth applications. -**Google** permite criar aplicações que podem **interagir em nome dos usuários** com vários **serviços Google**: Gmail, Drive, GCP... +**Google** permite criar aplicações que podem **interagir em nome dos usuários** com vários **Google services**: Gmail, Drive, GCP... -Ao criar uma aplicação para **agir em nome de outros usuários**, o desenvolvedor precisa criar um **app OAuth dentro do GCP** e indicar os escopos (permissões) que o app precisa para acessar os dados dos usuários.\ -Quando um **usuário** deseja **usar** essa **aplicação**, ele será **solicitado** a **aceitar** que a aplicação terá acesso aos seus dados especificados nos escopos. +Ao criar uma aplicação para **agir em nome de outros usuários**, o desenvolvedor precisa criar um **OAuth app inside GCP** e indicar os scopes (permissões) que a app precisa para acessar os dados dos usuários. Quando um **usuário** quiser **usar** essa **aplicação**, será **solicitado** que **aceite** que a aplicação terá acesso aos dados especificados nos scopes. -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. +Esta é uma forma muito atraente de **phish** usuários não técnicos para que usem **aplicações que acessam informações sensíveis**, porque eles podem não entender as consequências. No entanto, em contas organizacionais, existem maneiras de evitar que isso aconteça. -### Aviso de App Não Verificado +### Unverified App prompt -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. +Como mencionado, o Google sempre apresentará um **prompt para o usuário aceitar** as permissões que ele está concedendo à aplicação em seu nome. Contudo, se a aplicação for considerada **perigosa**, o Google mostrará **primeiro** um **prompt** indicando que ela é **perigosa** e **tornando mais difícil** para o usuário conceder as permissões à aplicação. -Esse aviso aparece em apps que: +This prompt appears in apps that: -- Usam qualquer escopo que pode acessar dados privados (Gmail, Drive, GCP, BigQuery...) -- Apps com menos de 100 usuários (apps > 100 um processo de revisão também é necessário para parar de mostrar o aviso de não verificado) +- Use any scope that can access private data (Gmail, Drive, GCP, BigQuery...) +- Apps with less than 100 users (apps > 100 a review process is also needed to stop showing the unverified prompt) -### Escopos Interessantes +### Interesting Scopes -[**Aqui**](https://developers.google.com/identity/protocols/oauth2/scopes) você pode encontrar uma lista de todos os escopos OAuth do Google. +[**Here**](https://developers.google.com/identity/protocols/oauth2/scopes) you can find a list of all the Google OAuth scopes. -- **cloud-platform**: Visualizar e gerenciar seus dados em serviços do **Google Cloud Platform**. Você pode se passar pelo usuário no GCP. -- **admin.directory.user.readonly**: Ver e baixar o diretório GSuite da sua organização. Obter nomes, telefones, URLs de calendário de todos os usuários. +- **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. -### Criar um App OAuth +### Create an OAuth App -**Comece criando um ID de Cliente OAuth** +**Start creating an OAuth Client ID** -1. Vá para [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) e clique em configurar a tela de consentimento. -2. Em seguida, você será perguntado se o **tipo de usuário** é **interno** (apenas para pessoas na sua organização) ou **externo**. Selecione o que melhor se adequa às suas necessidades -- Interno pode ser interessante se você já comprometeu um usuário da organização e está criando este App para phish outro. -3. Dê um **nome** ao app, um **e-mail de suporte** (note que você pode definir um e-mail de grupo do Google para tentar se anonimizar um pouco mais), um **logo**, **domínios autorizados** e outro **e-mail** para **atualizações**. -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 teste, apenas esses usuários poderão acessar o app, então certifique-se de **adicionar o e-mail que você vai phish**. +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 might be interesting you have already compromised a user of the organization and you are creating this App to phish another one. +3. Give a **name** to the app, a **support email** (note that you can set a googlegroup email to try to anonymize yourself a bit more), a **logo**, **authorized domains** and another **email** for **updates**. +4. **Select** the **OAuth scopes**. +- This page is divided in non sensitive permissions, sensitive permissions and restricted permissions. Eveytime you add a new permisison it's added on its category. Depending on the requested permissions different prompt will appear to the user indicating how sensitive these permissions are. +- Both **`admin.directory.user.readonly`** and **`cloud-platform`** are sensitive permissions. +5. **Add the test users.** As long as the status of the app is testing, only these users are going to be able to access the app so make sure to **add the email you are going to be phishing**. -Agora vamos obter **credenciais para uma aplicação web** usando o **ID de Cliente OAuth criado anteriormente**: +Now let's get **credentials for a web application** using the **previously created OAuth Client ID**: -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** -3. Defina os **origens Javascript** e **URIs de redirecionamento** necessários -- Você pode definir em ambos algo como **`http://localhost:8000/callback`** para teste -4. Obtenha suas **credenciais da aplicação** +1. Go back to [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), a different option will appear this time. +2. Select to **create credentials for a Web application** +3. Set needed **Javascript origins** and **redirect URIs** +- You can set in both something like **`http://localhost:8000/callback`** for testing +4. Get your application **credentials** -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). +Finally, lets **run a web application that will use the OAuth application credentials**. You can find an example 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 "" ``` -Vá para **`http://localhost:8000`**, clique no botão Login with Google, você será **solicitado** com uma mensagem como esta: +Acesse **`http://localhost:8000`**, clique no botão Login with Google, você será **solicitado** com uma mensagem como esta:
-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**: +A aplicação mostrará os **access and refresh token** que podem ser facilmente usados. Para mais informações sobre **como usar esses tokens, consulte**: {{#ref}} ../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md @@ -147,15 +146,74 @@ O aplicativo mostrará o **token de acesso e o token de atualização** que pode #### Usando `glcoud` -É possível fazer algo usando gcloud em vez do console da web, verifique: +É possível fazer algo usando gcloud em vez do console web, consulte: {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md {{#endref}} +#### Proteções de apps OAuth + +Por padrão, está configurado que qualquer usuário dentro de uma organização Workspace **pode aceitar qualquer OAuth app com quaisquer permissões**, mas é possível restringir isso para permitir apenas apps que solicitem as informações básicas necessárias para Sign in with Google ou para não permitir nenhum third-party app. + +Além disso, mesmo não permitindo confiar em apps externos de terceiros, é possível permitir **confiar em quaisquer apps internos** (apps criados dentro da organização). Essa confiança é configurada por **default**. + +
+ +### OAuth Consent Grant Abuse: Detecção & Resposta (Admin Reports) + +Quando um usuário autoriza um OAuth app, o Google Workspace registra isso na **Admin Reports OAuth Token Audit Activity** (application name `token`) com `events.name` definido como `authorize`. Esses eventos são a melhor telemetria para detectar consent phishing e rastrear o client ID e os scopes que foram concedidos. + +Campos-chave para extrair do evento de auditoria: + +- `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` + +**Baseline first (reduce noise):** construa um inventário dos client IDs e scopes existentes, e então acione alertas para consentimentos novos/raros. +```bash +gam all users print tokens todrive +``` +**Ideias de detecção (new/rare app + risky scopes):** + +- Alertar se um `client_id` **não estiver em uma allowlist aprovada** e **não tiver sido visto nos últimos X dias** (por exemplo, 90). +- Alertar se o `scope` concedido incluir escopos **de alto risco ou raros**, especialmente aqueles que permitem acesso em massa a dados ou impacto na cadeia de suprimentos, tais como: +- `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) +``` +**Resposta / contenção:** + +- Revogar tokens para o client ID OAuth malicioso: +```bash +gam all users delete tokens clientId +``` +- Bloqueie o OAuth client ID no Admin Console revogando o acesso da aplicação aos dados do Google. + +**Pivôs de threat hunting:** + +- Liste aplicativos externos consentidos por menos de N usuários (adoção rara). +- Revise o nome do aplicativo, publicador, permissões/scopes e o ID único da aplicação. +- Procure por aplicativos inativos que de repente passam a usar permissões arriscadas (possíveis ações subsequentes como phishing interno ou roubo de dados). + +**Mitigações:** + +- Restringir todo o acesso de aplicativos de terceiros (apenas aprovados pelo admin). +- Permitir acesso limitado para que os usuários possam consentir apenas nas informações básicas de perfil “Sign in with Google”. + ## Referências - [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, How do I 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}}