Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aparentemente, por defecto, en workspace los miembros pueden crear grupos y invitar a personas a ellos. Luego puedes modificar el correo que se enviará al usuario agregando algunos enlaces. El correo vendrá de una dirección de google, por lo que parecerá legítimo y la gente podría hacer clic en el enlace.
También es posible establecer la dirección FROM como el correo del grupo de Google para enviar más correos a los usuarios dentro del grupo, como en la siguiente imagen 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)
Podrías ser capaz de iniciar un chat con una persona solo teniendo su dirección de correo electrónico o enviar una invitación para hablar. Además, es posible crear un Espacio que puede tener cualquier nombre (por ejemplo, "Soporte de Google") y invitar a miembros a él. Si aceptan, podrían pensar que están hablando con Soporte de Google:
Sin embargo, en mis pruebas, los miembros invitados ni siquiera recibieron una invitación.
Puedes verificar cómo funcionó esto en el pasado en: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s
En el pasado era posible crear un documento aparentemente legítimo y en un comentario mencionar algún correo (como @user@gmail.com). Google enviaba un correo a esa dirección de correo notificando que fueron mencionados en el documento. Hoy en día, esto no funciona, pero si le das al correo de la víctima acceso al documento, Google enviará un correo indicando eso. Este es el mensaje que aparece cuando mencionas a alguien:
Las víctimas pueden tener mecanismos de protección que no permiten que los correos indicando que un documento externo fue compartido con ellos lleguen a su correo.
Puedes crear un evento de calendario y agregar tantas direcciones de correo de la empresa que estás atacando como tengas. Programa este evento de calendario en 5 o 15 minutos desde el tiempo actual. Haz que el evento parezca legítimo y pon un comentario y un título indicando que necesitan leer algo (con el enlace de phishing).
Esta es la alerta que aparecerá en el navegador con un título de reunión "Despedir Personas", por lo que podrías establecer un título más relacionado con phishing (e incluso cambiar el nombre asociado con tu correo).
Para que parezca menos sospechoso:
Configúralo para que los receptores no puedan ver a las otras personas invitadas
NO envíes correos notificando sobre el evento. Entonces, las personas solo verán su advertencia sobre una reunión en 5 minutos y que necesitan leer ese enlace.
Aparentemente, usando la API puedes establecer en True que las personas han aceptado el evento e incluso crear comentarios en su nombre.
Es posible crear un script en https://script.google.com/ y exponerlo como una aplicación web accesible por todos 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 esta página sin dejar de acceder al dominio:
Por ejemplo, al acceder a https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec verás:
Ten en cuenta que aparecerá una advertencia a medida que se cargue el contenido dentro de un iframe.
Es posible crear App Scripts adjuntos a documentos para intentar obtener acceso al token OAuth de una víctima, para más información consulta:
GWS - App ScriptsCualquiera de las técnicas anteriores puede ser utilizada para hacer que el usuario acceda a una aplicación OAuth de Google que solicitará al usuario algún acceso. Si el usuario confía en la fuente, puede confiar en la aplicación (incluso si está pidiendo permisos de alto privilegio).
Ten en cuenta que Google presenta un aviso poco atractivo advirtiendo que la aplicación no es de confianza en varios casos y los administradores de Workspace incluso pueden prevenir que las personas acepten aplicaciones OAuth.
Google permite crear aplicaciones que pueden interactuar en nombre de los 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 aplicación OAuth dentro de GCP e indicar los scopes (permisos) que la aplicación 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 phishing a usuarios no técnicos para que usen aplicaciones que acceden a información sensible porque pueden no entender las consecuencias. Sin embargo, en cuentas de organizaciones, hay formas de prevenir que esto suceda.
Como se mencionó, Google siempre presentará un aviso al usuario para aceptar los permisos que están otorgando 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 más que el usuario otorgue los permisos a la aplicación.
Este aviso aparece en aplicaciones que:
Usan cualquier scope que puede acceder a datos privados (Gmail, Drive, GCP, BigQuery...)
Aplicaciones con menos de 100 usuarios (aplicaciones > 100 también necesitan un proceso de revisión para dejar de mostrar el aviso de no verificada)
Aquí puedes encontrar una lista de todos los scopes de OAuth de Google.
cloud-platform: Ver y gestionar tus datos en los servicios de Google Cloud Platform. Puedes suplantar al usuario en GCP.
admin.directory.user.readonly: Ver y descargar el directorio de GSuite de tu organización. Obtener nombres, teléfonos, URLs de calendarios de todos los usuarios.
Comienza creando un ID de Cliente OAuth
Ve a https://console.cloud.google.com/apis/credentials/oauthclient y haz clic en configurar la pantalla de consentimiento.
Luego, se te preguntará si el tipo de usuario es interno (solo para personas en tu organización) o externo. Selecciona el que se ajuste a tus necesidades.
Interno puede ser interesante si ya has comprometido a un usuario de la organización y estás creando esta aplicación para phishing a otro.
Da un nombre a la aplicación, un correo electrónico de soporte (ten en cuenta que puedes establecer un correo electrónico de grupo de Google para intentar anonimizarte un poco más), un logo, dominios autorizados y otro correo electrónico para actualizaciones.
Selecciona los scopes de OAuth.
Esta página está dividida en permisos no sensibles, permisos sensibles y permisos restringidos. Cada vez que agregas un nuevo permiso, se añade a su categoría. Dependiendo de los permisos solicitados, aparecerán diferentes avisos al usuario indicando cuán sensibles son estos permisos.
Tanto admin.directory.user.readonly como cloud-platform son permisos sensibles.
Agrega los usuarios de prueba. Mientras el estado de la aplicación sea de prueba, solo estos usuarios podrán acceder a la aplicación, así que asegúrate de agregar el correo electrónico que vas a phishing.
Ahora obtengamos credenciales para una aplicación web usando el ID de Cliente OAuth creado previamente:
Regresa a https://console.cloud.google.com/apis/credentials/oauthclient, esta vez aparecerá una opción diferente.
Selecciona crear credenciales para una aplicación web.
Establece los orígenes de Javascript y URIs de redirección necesarios.
Puedes establecer en ambos algo como http://localhost:8000/callback para pruebas.
Obtén las credenciales de tu aplicación.
Finalmente, ejecutemos una aplicación web que usará las credenciales de la aplicación OAuth. Puedes encontrar un ejemplo en https://github.com/carlospolop/gcp_oauth_phishing_example.
Ve a http://localhost:8000, haz clic en el botón Iniciar sesión con Google, se te pedirá un mensaje como este:
La aplicación mostrará el token de acceso y el token de actualización que se pueden usar fácilmente. Para más información sobre cómo usar estos tokens, consulta:
GCP - Token Persistance
glcoudEs posible hacer algo usando gcloud en lugar de la consola web, consulta:
GCP - ClientAuthConfig Priveschttps://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 - Mike Felch y Beau Bullock - OK Google, ¿Cómo hago un Red Team en GSuite?
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
