Español - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Conditional Access Policies / MFA Bypass

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Información Básica

Las políticas de acceso condicional de Azure son reglas establecidas en Microsoft Azure para hacer cumplir controles de acceso a los servicios y aplicaciones de Azure basados en ciertas condiciones. Estas políticas ayudan a las organizaciones a asegurar sus recursos aplicando los controles de acceso adecuados en las circunstancias correctas. Las políticas de acceso condicional básicamente definen Quién puede acceder a Qué desde Dónde y Cómo.

Aquí tienes un par de ejemplos:

  1. Política de Riesgo de Inicio de Sesión: Esta política podría configurarse para requerir autenticación multifactor (MFA) cuando se detecta un riesgo de inicio de sesión. Por ejemplo, si el comportamiento de inicio de sesión de un usuario es inusual en comparación con su patrón regular, como iniciar sesión desde un país diferente, el sistema puede solicitar una autenticación adicional.

  2. Política de Cumplimiento de Dispositivos: Esta política puede restringir el acceso a los servicios de Azure solo a dispositivos que cumplan con los estándares de seguridad de la organización. Por ejemplo, el acceso solo podría permitirse desde dispositivos que tengan software antivirus actualizado o que estén ejecutando una cierta versión del sistema operativo.

Bypass de Políticas de Acceso Condicional

Es posible que una política de acceso condicional esté verificando alguna información que pueda ser fácilmente manipulada permitiendo un bypass de la política. Y si, por ejemplo, la política estaba configurando MFA, el atacante podrá evadirla.

Plataformas de Dispositivos - Condición del Dispositivo

Es posible establecer una condición basada en la plataforma del dispositivo (Android, iOS, Windows, macOS), sin embargo, esto se basa en el user-agent por lo que es bastante fácil de evadir. Incluso si se hacen cumplir MFA en todas las opciones, si se utiliza un user-agent que no reconoce se podrá evadir el MFA.

Ubicaciones: Países, rangos de IP - Condición del Dispositivo

Por supuesto, si esto está configurado en la política condicional, un atacante podría simplemente usar una VPN en el país permitido o intentar encontrar una forma de acceder desde una dirección IP permitida para evadir estas condiciones.

Aplicaciones de Cliente de Office365

Se podría indicar que si los clientes acceden a las aplicaciones de Office 365 desde el navegador necesitan MFA:

Para evadir esto, es posible fingir que se inicia sesión en una aplicación desde una aplicación de escritorio (como en Microsoft Teams en el siguiente ejemplo) lo cual evadirá la protección:

roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokrns-stdout

<token>

Dado que la aplicación Microsoft Teams tiene muchos permisos, podrás utilizar ese acceso.

Puedes encontrar la ID de más aplicaciones públicas con permisos predefinidos de Office365 en la base de datos de roadtools:

SELECT appId, displayName FROM ApplicationRefs WHERE publicCLient = 1 ORDER BY displayName ASC

Este ataque es especialmente interesante porque por defecto las aplicaciones públicas de Office365 tendrán permisos para acceder a algunos datos.

Otras aplicaciones

Por defecto, otras aplicaciones creadas por usuarios no tendrán permisos y podrían ser privadas. Sin embargo, los usuarios también podrían crear aplicaciones públicas otorgándoles algunos permisos.

Un escenario potencial donde se establece una política para requerir MFA para acceder a una aplicación cuando el usuario está utilizando un navegador (quizás porque es una aplicación web y por lo tanto será la única forma), si hay una aplicación proxy -una aplicación permitida para interactuar con otras aplicaciones en nombre de los usuarios-, el usuario podría iniciar sesión en la aplicación proxy y luego a través de esta aplicación proxy iniciar sesión en la aplicación inicialmente protegida por MFA.

Consulte las técnicas Invoke-MFASweep y donkeytoken.

Otros Bypasses de MFA de Az

Tono de llamada

Una opción de Azure MFA es recibir una llamada en el número de teléfono configurado donde se pedirá al usuario que envíe el carácter #.

Como los caracteres son solo tonos, un atacante podría comprometer el mensaje de buzón de voz del número de teléfono, configurar como mensaje el tono de # y luego, al solicitar el MFA asegurarse de que el teléfono de la víctima esté ocupado (llamándolo) para que la llamada de Azure se redirija al buzón de voz.

Dispositivos compatibles

Las políticas a menudo solicitan un dispositivo compatible o MFA, por lo que un atacante podría registrar un dispositivo compatible, obtener un token PRT y burlar de esta manera el MFA.

Comience registrando un dispositivo compatible en Intune, luego obtenga el PRT con:

$prtKeys = Get-AADIntuneUserPRTKeys - PfxFileName .\<uuid>.pfx -Credentials $credentials

$prtToken = New-AADIntUserPRTToken -Settings $prtKeys -GertNonce

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

Encuentra más información sobre este tipo de ataque en la siguiente página:

pageAz - Pass the PRT

Herramientas

roadrecon

Obtener todas las políticas

roadrecon plugin policies

Invoke-MFASweep

MFASweep es un script de PowerShell que intenta iniciar sesión en varios servicios de Microsoft utilizando un conjunto de credenciales proporcionado y tratará de identificar si MFA está habilitado. Dependiendo de cómo estén configuradas las políticas de acceso condicional y otros ajustes de autenticación multifactor, algunos protocolos pueden terminar quedando en un solo factor. También tiene una verificación adicional para configuraciones de ADFS y puede intentar iniciar sesión en el servidor ADFS local si se detecta.

Invoke-MFASweep -Username <username> -Password <pass>

donkeytoken

Donkey token es un conjunto de funciones que tienen como objetivo ayudar a los consultores de seguridad que necesitan validar las Políticas de Acceso Condicional, pruebas para portales de Microsoft habilitados para 2FA, etc.

Import-Module 'C:\Users\Administrador\Desktop\Azure\Modulos ps1\donkeytoken' -Force

Probar cada portal si es posible iniciar sesión sin MFA:

Test-MFA -credential $cred -Verbose -Debug -InformationAction Continue

Debido a que el portal de Azure no está restringido, es posible recopilar un token desde el punto final del portal para acceder a cualquier servicio detectado por la ejecución anterior. En este caso, se identificó Sharepoint y se solicita un token para acceder a él:

$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
Read-JWTtoken -token $token.access_token

Suponiendo que el token tenga el permiso Sites.Read.All (de Sharepoint), incluso si no puedes acceder a Sharepoint desde la web debido a MFA, es posible usar el token para acceder a los archivos con el token generado:

$data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl

Referencias

Aprende hacking en AWS de cero a héroe con htARTE (Experto en Red Team de AWS de HackTricks)!

Otras formas de apoyar a HackTricks:

AnteriorAz - AzureAD (AAD)SiguienteAz - Dynamic Groups Privesc

Última actualización