GWS - Google Platforms Phishing

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Metodología Genérica de Phishing

Phishing Methodology - HackTricks

Google Groups Phishing

Aparentemente, por defecto, en workspace los miembros can create groups and invite people to them. Puedes luego modificar el correo que se enviará al usuario añadiendo algunos enlaces. El email will come from a google address, por lo que parecerá legit y la gente podría hacer clic en el enlace.

También es posible establecer la dirección FROM como el Google group email para enviar more emails to the users inside the group, como en la imagen siguiente donde se creó el grupo google--support@googlegroups.com y se envió un correo a todos los miembros del grupo (que fueron añadidos sin ningún consentimiento)

Google Chat Phishing

Es posible que puedas start a chat con una persona solo teniendo su dirección de email o enviar una invitation to talk. Además, es posible create a Space que puede tener cualquier nombre (p. ej. “Google Support”) e invite miembros a él. Si aceptan podrían pensar que están hablando con Google Support:

Tip

En mis pruebas, sin embargo, los miembros invitados ni siquiera recibieron una invitación.

Puedes ver cómo funcionó esto en el pasado en: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s

Google Doc Phishing

En el pasado era posible crear un apparently legitimate document y luego en un comentario mention some email (like @user@gmail.com). Google sent an email to that email address notificando que fueron mencionados en el documento.
Hoy en día esto no funciona, pero si give the victim email access to the document Google enviará un correo indicándolo. Este es el mensaje que aparece cuando mencionas a alguien:

Tip

Las víctimas pueden tener mecanismos de protección que impiden que correos que indican que un documento externo fue compartido con ellas lleguen a su email.

Google Calendar Phishing

Puedes create a calendar event y añadir tantas direcciones de email de la empresa que estás atacando como tengas. Programa este evento de calendario a 5 or 15 min desde el momento actual. Haz que el evento parezca legítimo y put a comment and a title indicating that they need to read something (con el phishing link).

Esta es la alerta que aparecerá en el navegador con un título de reunión “Firing People”, así que podrías poner un título más tipo phishing (e incluso cambiar el nombre asociado a tu email).

Para que parezca menos sospechoso:

  • Configúralo de modo que receivers cannot see the other people invited
  • Haz NOT send emails notifying about the event. Entonces, la gente solo verá su aviso sobre una reunión en 5mins y que necesitan leer ese enlace.
  • Aparentemente usando la API puedes poner en True que las people han accepted el evento e incluso crear comments on their behalf.

App Scripts Redirect Phishing

Es posible crear un script en https://script.google.com/ y expose it as a web application accessible by everyone que usará el dominio legítimo script.google.com.
Con algo de código como el siguiente, un atacante podría hacer que el script cargue contenido arbitrario en esa página sin dejar de acceder al dominio:

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 verás:

Tip

Ten en cuenta que aparecerá una advertencia ya que el contenido se carga dentro de un iframe.

App Scripts OAuth Phishing

Es posible crear App Scripts adjuntos a documentos para intentar obtener acceso al token OAuth de una víctima; para más información revisa:

GWS - App Scripts

OAuth Apps Phishing

Cualquiera de las técnicas anteriores puede usarse para hacer que el usuario acceda a una Google OAuth application que le solicitará cierto acceso. Si el usuario confía en la fuente, podría confiar en la aplicación (incluso si solicita permisos muy privilegiados).

Note

Ten en cuenta que google presenta un aviso poco amigable advirtiendo que la aplicación no es de confianza en varios casos y los admins de Workspace incluso pueden impedir que la gente acepte aplicaciones OAuth.

Google permite crear aplicaciones que pueden actuar en nombre de usuarios con varios servicios de Google: Gmail, Drive, GCP…

Al crear una aplicación para actuar en nombre de otros usuarios, el desarrollador necesita crear una OAuth app inside GCP e indicar los scopes (permisos) que la app necesita para acceder a los datos de los usuarios.
Cuando un usuario quiere usar esa aplicación, se le pedirá que acepte que la aplicación tendrá acceso a sus datos especificados en los scopes.

Esta es una forma muy jugosa de phish a usuarios no técnicos para que usen aplicaciones que acceden a información sensible, porque podrían no entender las consecuencias. Sin embargo, en cuentas organizacionales existen formas de evitar que esto ocurra.

Unverified App prompt

Como se mencionó, google siempre presentará un aviso al usuario para aceptar los permisos que está cediendo a la aplicación en su nombre. Sin embargo, si la aplicación se considera peligrosa, google mostrará primero un aviso indicando que es peligrosa y dificultando que el usuario conceda los permisos a la app.

Este aviso aparece en apps que:

  • Usan cualquier scope que pueda acceder a datos privados (Gmail, Drive, GCP, BigQuery…)
  • Apps con menos de 100 usuarios (para apps > 100 es necesario un proceso de revisión para dejar de mostrar el aviso de no verificada)

Interesting Scopes

Here puedes encontrar una lista de todos los 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. Ve a https://console.cloud.google.com/apis/credentials/oauthclient y haz clic en configure the consent screen.
  2. Luego, se te preguntará si el user type es internal (solo para personas de tu org) o external. Selecciona el que se ajuste a tus necesidades.
  • Internal puede ser interesante si ya has comprometido a un usuario de la organización y estás creando esta App para phish a otro.
  1. Dale un nombre a la app, un support email (ten en cuenta que puedes poner un correo de googlegroup para intentar anonimizarte un poco más), un logo, authorized domains y otro email para updates.
  2. Selecciona los OAuth scopes.
  • Esta página está dividida en permisos no sensibles, permisos sensibles y permisos restringidos. Cada vez que añades un permiso nuevo se añade a su categoría. Dependiendo de los permisos solicitados aparecerán distintos avisos al usuario indicando lo sensibles que son esos permisos.
  • Tanto admin.directory.user.readonly como cloud-platform son permisos sensibles.
  1. Añade los test users. Mientras el estado de la app sea testing, solo estos usuarios podrán acceder a la app, así que asegúrate de añadir el email que vas a phish.

Ahora obtengamos credentials for a web application usando el OAuth Client ID previamente creado:

  1. Vuelve a https://console.cloud.google.com/apis/credentials/oauthclient, esta vez aparecerá una opción diferente.
  2. Selecciona crear credentials for a Web application
  3. Configura los Javascript origins y redirect URIs que necesites.
  • Puedes poner en ambos algo como http://localhost:8000/callback para pruebas.
  1. Obtén las credentials de tu aplicación.

Finalmente, ejecuta una web application que use las credentials de la OAuth application. Puedes encontrar un ejemplo en 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>"

Vaya a http://localhost:8000, haga clic en el botón Login with Google, y se le mostrará un mensaje como este:

La aplicación mostrará los access and refresh token que pueden usarse fácilmente. Para más información sobre cómo usar estos tokens, consulte:

GCP - Token Persistence

Using glcoud

Es posible hacer ciertas acciones usando gcloud en lugar de la consola web; consulte:

GCP - ClientAuthConfig Privesc

Protecciones de aplicaciones OAuth

Por defecto está configurado que cualquier usuario dentro de una organización Workspace puede aceptar cualquier OAuth app con cualquier permisos, pero es posible restringir eso para que solo se permitan aplicaciones que soliciten la información básica necesaria para Sign in with Google, o para no permitir ninguna third-party apps.

Además, incluso sin permitir confiar en third-party apps externas, es posible permitir confiar en cualquier aplicación interna (apps creadas dentro de la organización). Esta confianza está configurada por defecto.

Abuso de concesión de consentimiento OAuth: Detección y Respuesta (Admin Reports)

Cuando un usuario autoriza una OAuth app, Google Workspace lo registra en la Admin Reports OAuth Token Audit Activity (application name token) con events.name establecido en authorize. Estos eventos son la mejor telemetría para detectar consent phishing y rastrear el client ID y los scopes que se concedieron.

Campos clave para extraer del evento de auditoría:

  • 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

Establecer una línea base primero (reducir ruido): crear un inventario de los client IDs y scopes existentes, y luego alertar sobre consentimientos nuevos/raros.

gam all users print tokens todrive

Ideas de detección (aplicación nueva/rara + scopes riesgosos):

  • Alerta si un client_id no está en una allowlist aprobada y no se ha visto en los últimos X días (p. ej., 90).
  • Alerta si el scope concedido incluye scopes de alto riesgo o raros, especialmente aquellos que permiten acceso masivo a datos o impacto en la cadena de suministro, 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)

Respuesta / contención:

  • Revocar tokens para el OAuth client ID malicioso:
gam all users delete tokens clientId <client_id>
  • Bloquear el client ID de OAuth en el Admin Console revocando el acceso de la aplicación a los datos de Google.

Threat hunting pivots:

  • Listar apps externas consentidas por menos de N usuarios (adopción rara).
  • Revisar nombre de la app, publicador, permisos/scopes y el ID único de la aplicación.
  • Buscar apps inactivas que de repente usan permisos riesgosos (posibles acciones posteriores como internal phishing o robo de datos).

Mitigaciones:

  • Restringir todo el acceso de apps de terceros (solo aprobadas por el administrador).
  • Permitir acceso limitado para que los usuarios solo puedan consentir la información básica de perfil de “Sign in with Google”.

Referencias

Tip

Aprende y practica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks