GWS - Google Platforms Phishing

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks

Metodologia Genérica de Phishing

Phishing Methodology - HackTricks

Google Groups Phishing

Aparentemente, por padrão, membros do workspace podem criar grupos 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 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 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 chegaram a receber um convite.

Você pode ver como isso funcionou no passado em: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s

Google Doc Phishing

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 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 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 “Firing People”, então você poderia definir um título mais convincente (e até alterar o nome associado ao seu email).

Para deixá-lo menos suspeito:

  • 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/ 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:

function doGet() {
return HtmlService.createHtmlOutput(
'<meta http-equiv="refresh" content="0;url=https://cloud.hacktricks.wiki/en/pentesting-cloud/workspace-security/gws-google-platforms-phishing/index.html#app-scripts-redirect-phishing">'
).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL)
}

For example accessing https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec you will see:

Tip

Observe que um aviso aparecerá, pois o conteúdo é carregado dentro de um iframe.

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, veja:

GWS - App Scripts

OAuth Apps Phishing

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

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 Google services: Gmail, Drive, GCP…

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 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.

Unverified App prompt

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.

This prompt appears in apps that:

  • 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)

Interesting Scopes

Here you can find a list of all the Google OAuth scopes.

  • cloud-platform: View and manage your data across Google Cloud Platform services. You can impersonate the user in GCP.
  • admin.directory.user.readonly: See and download your organization’s GSuite directory. Get names, phones, calendar URLs of all the users.

Create an OAuth App

Start creating an OAuth Client ID

  1. Go to https://console.cloud.google.com/apis/credentials/oauthclient and click on configure the consent screen.
  2. Then, you will be asked if the user type is internal (only for people in your org) or external. Select the one that suits your needs
  • Internal might be interesting you have already compromised a user of the organization and you are creating this App to phish another one.
  1. 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.
  2. 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.
  1. 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.

Now let’s get credentials for a web application using the previously created OAuth Client ID:

  1. Go back to 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
  1. Get your application credentials

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.

git clone ttps://github.com/carlospolop/gcp_oauth_phishing_example
cd gcp_oauth_phishing_example
pip install flask requests google-auth-oauthlib
python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"

Acesse http://localhost:8000, clique no botão Login with Google, você será solicitado com uma mensagem como esta:

A aplicação mostrará os access and refresh token que podem ser facilmente usados. Para mais informações sobre como usar esses tokens, consulte:

GCP - Token Persistence

Usando glcoud

É possível fazer algo usando gcloud em vez do console web, consulte:

GCP - ClientAuthConfig Privesc

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.

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
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:
gam all users delete tokens clientId <client_id>
  • 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

Tip

Aprenda e pratique AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprenda e pratique Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoie o HackTricks