Problema

Los entornos de Azure Entra ID (antes Azure AD) permiten que aplicaciones de terceros soliciten permisos a recursos corporativos mediante flujos OAuth. Cuando un atacante consigue que un usuario legítimo otorgue consentimientos a una aplicación maliciosa, se abre la puerta a la técnica conocida como Illicit Consent Grant (T1528). En producción, este vector se manifiesta como:

  • Consentimientos inesperados en el portal de Azure.
  • Tokens de acceso que otorgan privilegios a recursos críticos.
  • Alertas de actividad sospechosa que a menudo se pierden entre el ruido de logs.

Los equipos de seguridad que no disponen de un entorno controlado para reproducir el flujo, validar detecciones y probar mitigaciones, suelen descubrir el problema solo después de que un atacante haya comprometido datos. La falta de un laboratorio reproducible dificulta la calibración de reglas de detección en Azure Sentinel y la aplicación de hardening coherente.

Causa

El ataque se basa en tres componentes que aparecen con frecuencia en entornos reales:

  1. Aplicaciones registradas sin revisión de permisos – Los administradores a veces crean aplicaciones de prueba o delegan el registro a equipos de desarrollo sin validar los scopes solicitados. Cuando el scope incluye permisos de alto nivel (por ejemplo, Directory.Read.All), cualquier usuario que consienta la aplicación le otorga esos derechos a la entidad maliciosa.

  2. Consentimiento de usuarios finales – En escenarios de BYOD o de usuarios que aceptan rápidamente diálogos de permiso, el consentimiento se otorga sin inspección. Los atacantes pueden usar phishing o ingeniería social para que la víctima haga clic en un enlace que inicia el flujo OAuth.

  3. Falta de monitorización de consentimientos – Azure registra eventos de ConsentGrant en el log de actividad, pero si no se configuran alertas específicas, esos eventos se pierden. Además, los tokens de acceso pueden ser reutilizados sin que se genere un nuevo evento de auditoría.

Variaciones comunes incluyen:

  • Consentimientos delegados vs. de aplicación – Los ataques pueden aprovechar ambos tipos; los delegados son más fáciles de obtener mediante phishing, mientras que los de aplicación pueden ser creados por un atacante que ya controla una cuenta con privilegios de registro.
  • Uso de aplicaciones multi‑tenant – Una aplicación registrada en otro tenant puede solicitar consentimientos en el tenant objetivo si el administrador la ha aceptado previamente.
  • Persistencia mediante refresh tokens – Una vez obtenido el token, el atacante puede refrescarlo indefinidamente, manteniendo acceso prolongado.

Solución

Una solución reutilizable combina tres capas: preparación del laboratorio, detección en tiempo real y hardening de la configuración.

1. Construir un laboratorio reproducible

  1. Crear un tenant de prueba – Usa una suscripción de Azure gratuita o una cuenta de desarrollo. Evita mezclar este tenant con entornos productivos.

  2. Registrar una aplicación maliciosa – En Azure Portal, registra una aplicación con Redirect URI a https://localhost. No asignar permisos inicialmente.

  3. Simular el flujo de consentimiento – Desde una cuenta de usuario con privilegios limitados, ejecuta la URL de autorización:

    https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize?
client_id={app-id}&response_type=code&redirect_uri=https%3A%2F%2Flocalhost&
scope=User.Read+Directory.Read.All&state=12345

    Acepta el consentimiento cuando el portal lo solicite. El código de autorización se intercambia por un token de acceso y un refresh token.

  4. Inyectar actividad en Azure Sentinel – Conecta el tenant de prueba a un workspace de Log Analytics y habilita el diagnóstico de Azure AD (AuditLogs y SignInLogs). Esto garantiza que los eventos de ConsentGrant y los tokens emitidos lleguen a Sentinel.

2. Detección con Azure Sentinel/KQL

Implementa reglas de detección que busquen patrones típicos:

  • Consentimientos fuera de lo esperado – Filtra eventos donde el clientId no pertenece a una lista blanca de aplicaciones corporativas.
  • Elevación de scopes – Detecta consentimientos que incluyan permisos de nivel Directory.* o Application.* otorgados por usuarios sin roles de administrador.
  • Uso de refresh tokens sospechosos – Busca grant_type=refresh_token en SignInLogs que provengan de la misma aplicación pero desde IPs diferentes.

Ejemplo de regla KQL (simplificada):

AuditLogs
| where OperationName == "ConsentGrant"
| where TargetResources[0].type == "Application"
| where TargetResources[0].displayName !in ("AppCorp1","AppCorp2")
| project TimeGenerated, InitiatedBy.userPrincipalName, TargetResources[0].displayName, AdditionalDetails

Esta consulta muestra consentimientos a aplicaciones no autorizadas. Puedes combinarla con una lista de allowedAppIds para reducir falsos positivos.

3. Hardening de la configuración

  • Restricción de consentimientos – En Azure AD, habilita la política User consent for apps y desactiva la opción de que usuarios concedan permisos a aplicaciones de terceros sin aprobación administrativa.
  • Revisión periódica de aplicaciones – Programa auditorías mensuales que comparen los clientId registrados con la lista de aplicaciones aprobadas. Usa Azure AD PowerShell para exportar la lista: 
    Get-AzureADApplication | select ObjectId, DisplayName, IdentifierUris
  • Política de Conditional Access – Crea una política que requiera MFA para cualquier intento de ConsentGrant. Esto eleva la fricción para ataques basados en phishing.
  • Desactivar aplicaciones multi‑tenant no necesarias – En el registro de la aplicación, marca Supported account types como Accounts in this organizational directory only.

4. Automatización de respuestas

Integra Azure Logic Apps o Azure Functions para cerrar automáticamente aplicaciones sospechosas:

az ad app delete --id <clientId>

Puedes disparar este comando desde una alerta de Sentinel usando un playbook. Asegúrate de incluir una fase de revisión manual para evitar eliminar aplicaciones legítimas.

Cuándo aplicar esta solución

Aplica este enfoque cuando:

  • Detectes consentimientos inesperados en el portal de Azure.
  • Veas tokens de acceso con scopes de alto nivel emitidos a aplicaciones desconocidas.
  • Quieras validar la efectividad de tus reglas de detección antes de implementarlas en producción.

No es necesario montar el laboratorio si ya cuentas con un entorno de pruebas que replica tu arquitectura de Azure AD y tienes reglas de detección en producción. En ese caso, enfócate en la capa de hardening y en la automatización de respuestas.

Código

# Exportar lista de aplicaciones registradas
az ad app list --output json > apps.json

# Filtrar aplicaciones que no están en la whitelist
jq '.[] | select(.appId | IN("appId1","appId2") | not) | {appId, displayName}' apps.json

Verificación

  1. Reproducir el flujo – Ejecuta la URL de autorización desde una cuenta de prueba y confirma que se genera un evento ConsentGrant en Log Analytics.
  2. Validar la regla KQL – Abre Azure Sentinel, ejecuta la consulta mostrada y verifica que el evento aparece en los resultados.
  3. Probar la política de MFA – Intenta conceder consentimiento a una aplicación nueva; el portal debe solicitar MFA antes de completar el proceso.
  4. Ejecutar el playbook – Genera una alerta de ConsentGrant para una aplicación no autorizada y confirma que el playbook elimina la aplicación y registra la acción en el audit log.

Notas adicionales

  • Las alertas de ConsentGrant pueden generar ruido en entornos con cientos de aplicaciones internas. Ajusta la whitelist regularmente y usa etiquetas (tags) en Azure AD para clasificar aplicaciones.
  • Los refresh tokens pueden permanecer válidos hasta 90 días. Si revocas una aplicación, también debes revocar sus tokens usando Revoke-AzureADUserAllRefreshToken -ObjectId <userObjectId>.
  • En escenarios híbridos (AD on‑prem + Entra ID), asegúrate de que Azure AD Connect no sincronice automáticamente aplicaciones no deseadas desde el directorio local.
  • La detección basada en IP puede fallar en entornos con VPN o Azure Front Door. Complementa con análisis de comportamiento (anomalías de tiempo, frecuencia de uso).