Acceso condicional Azure: brechas y bypass MFA

Que es el acceso condicional Azure?

El acceso condicional Azure es el motor de decision de Microsoft Entra ID para evaluar quien entra, desde donde entra, a que aplicacion entra y con que controles debe autenticarse. El problema no es solo la ausencia de MFA. Las brechas reales aparecen cuando el tenant mezcla exclusiones antiguas, clientes legacy, politicas en modo report-only, reglas distintas para admins y usuarios normales, y confianza excesiva en seales de otros tenants o de dispositivos no validados.

Microsoft documenta que Security Defaults ofrece una baseline minima para tenants pequenos, mientras que Conditional Access permite una politica mas precisa para administradores, workforce identities, invitados y aplicaciones concretas. Si desactiva Security Defaults y no construye una baseline equivalente, termina con zonas enteras del tenant fuera de control. Y si construye muchas politicas sin revisar como se aplican de verdad, el resultado tampoco es seguro: un tenant puede tener docenas de politicas y seguir dejando pasar inicios de sesion peligrosos.

Acceso condicional Azure: donde suelen abrirse las brechas

Los fallos mas comunes no son exoticos. Suelen ser decisiones operativas acumuladas con el tiempo.

Brecha	Como aparece	Por que es peligrosa
Exclusiones heredadas	cuentas break-glass, service accounts o grupos temporales nunca revisados	una excluson pequena puede convertirse en puerta permanente
Clientes legacy	clientes y protocolos que no completan MFA moderno o quedan fuera de la politica	una password robada recupera valor inmediatamente
Cobertura incompleta	no hay politica separada para admins, invitados o apps sensibles	identidades con distinto riesgo acaban bajo el mismo control minimo
MFA debil	cualquier segundo factor sirve para todo	el tenant no diferencia acceso sensible de acceso normal
Report-only perpetuo	politicas creadas para probar y nunca exigidas	la organizacion cree que protege algo que en realidad solo observa
Riesgo no usado	no se usan sign-in risk o user risk cuando la licencia y el modelo lo permiten	el tenant no reacciona a seales de compromiso ya detectadas por Entra

Como se convierte en una ruta de ataque

Paso 1 - El atacante consigue una credencial valida

Puede ser password spraying, phishing, robo de token o reutilizacion de credenciales. A partir de ahi, el acceso depende de la politica realmente aplicada, no de la politica que el equipo cree tener documentada.

Paso 2 - Encuentra una superficie fuera de la baseline

Las superficies tipicas son cuentas excluidas, aplicaciones antiguas, invitados externos, procesos administrativos no cubiertos o clientes que siguen usando flujos no equivalentes a la autenticacion moderna que la organizacion quiere imponer.

Paso 3 - Aprovecha una combinacion de excepcion y control debil

Si la cuenta esta fuera de la politica correcta, si el segundo factor aceptado es demasiado debil para el recurso, o si la politica no se aplica a la poblacion adecuada, la proteccion cae aunque el tenant "tenga MFA".

Paso 4 - Consolida el acceso

Una vez dentro, el atacante busca persistencia: registrar un metodo, crear una app, aprovechar acceso invitado, elevar privilegios o moverse hacia una cuenta que si tenga mas valor. Conditional Access mal afinado no provoca solo un inicio de sesion inseguro; cambia el coste total de comprometer el tenant.

Que debe auditar primero

1. La baseline minima del tenant

Si el tenant usa Security Defaults, confirme que siguen activados y que el negocio no depende de excepciones incompatibles. Si usa Conditional Access, confirme que hay una baseline explicita para:

administradores
workforce identities
guest y external users
aplicaciones o recursos de alto impacto

2. Las exclusiones

Toda politica de Conditional Access debe revisarse por sus exclusiones antes que por sus controles. Documente por que existe cada exclusion, quien la aprobo, cuando se reviso por ultima vez y que control compensatorio la cubre.

3. Los clientes y flujos de autenticacion

Revise que ningun cliente o flujo evite el control esperado. La pregunta practica es: que inicios de sesion siguen siendo exitosos con solo password o con un segundo factor demasiado debil para administracion?

4. Las poblaciones de alto riesgo

Administradores, cuentas de emergencia, invitados, cuentas de automatizacion y aplicaciones empresariales no deben heredarse unas a otras la misma politica por comodidad. Incluso cuando la politica es comun, la validacion tiene que demostrar que el control se aplica a cada poblacion como se espera.

Telemetria y deteccion

Los logs de sign-in y de audit son la fuente de verdad. Mire tanto lo exitoso como lo bloqueado.

Que buscar

sign-ins donde la politica no se aplico por exclusion
uso de client apps antiguas o inesperadas
politicas en report-only que siguen produciendo actividad real
cambios de metodos de autenticacion tras un login sospechoso
administradores que siguen entrando con una combinacion de factores demasiado debil

Consultas orientativas

SigninLogs
| where ConditionalAccessStatus != "success"
| project TimeGenerated, UserPrincipalName, AppDisplayName, ClientAppUsed, ConditionalAccessStatus, IPAddress

SigninLogs
| where ClientAppUsed in ("Exchange ActiveSync", "IMAP", "POP", "SMTP", "Other clients")
| project TimeGenerated, UserPrincipalName, ClientAppUsed, AppDisplayName, ConditionalAccessStatus

AuditLogs
| where OperationName has_any ("Update conditional access policy", "Add authentication method", "Update user")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources

Remediacion que vale la pena

Defina una baseline corta y exigible

Empiece por pocas politicas claras, no por muchas politicas ambiguas. Para muchos tenants, la base razonable es:

admins con MFA fuerte o authentication strength adecuada
guest y external users bajo politica propia
bloqueo de clientes o flujos que no deban seguir autenticando
politicas de riesgo si su modelo de licencia y operacion lo soporta

Revise y minimice exclusiones

Las cuentas break-glass pueden necesitar un tratamiento diferente, pero no deben convertirse en excusa para dejar fuera grupos enteros. Toda exclusion debe tener owner y fecha de revision.

No confunda presencia de MFA con resistencia real

Para acceso administrativo o a recursos sensibles, evale si necesita phishing-resistant MFA o al menos una politica de metodos de autenticacion mas estricta. El problema no es "tener o no tener MFA"; es si el factor exigido es adecuado para el valor del acceso.

Valide tambien invitados y relaciones externas

Una politica excelente para empleados y una politica inexistente para guest users no es una baseline segura. Revise Conditional Access junto con External collaboration settings, cross-tenant access settings y Authentication methods policy.

Como validar despues del cambio

pruebe un login de admin y confirme el control exacto exigido
pruebe un invitado y confirme que no hereda una politica mas debil de la prevista
revise que las exclusiones restantes tienen justificacion escrita
confirme que las politicas criticas ya no estan en report-only
verifique en logs que los clientes y flujos que queria bloquear ya no obtienen sesiones exitosas

Authentication strengths y metodos permitidos

Una politica de Conditional Access no se puede leer bien sin mirar al mismo tiempo la Authentication methods policy y, cuando aplique, las authentication strengths. Ese es el punto donde muchos tenants fallan: exigen MFA pero siguen permitiendo una combinacion de metodos demasiado debil para administracion, o mantienen metodos heredados porque nadie quiere romper el registro de usuarios antiguos. Para un equipo tecnico, la pregunta util es concreta: que metodos siguen siendo aceptables para admins, para invitados y para workforce identities de alto riesgo, y quien aprobo esa decision.

Cuando la organizacion ya usa authentication strengths, la validacion no deberia quedarse en "la politica pide MFA". Debe demostrar que el recurso o la poblacion sensible realmente exige la fuerza correcta y que no existe una exclusion que vuelva a dejar el login en un simple password mas factor debil.

Report-only y clientes legacy: como salir del limbo

El modo report-only es util para probar, pero se convierte rapidamente en una fuente de autoengano si nadie define una fecha de salida. Del mismo modo, los clientes legacy suelen quedarse vivos por una dependencia historica que nadie documenta bien. Un plan serio de remediacion deberia listar cada politica critica que sigue en report-only, cada protocolo o client app que todavia necesita soporte y la fecha en la que ambos dejaran de ser excepciones. Sin ese inventario, el tenant no tiene una estrategia de cierre: solo tiene observacion pasiva.

Matriz de validacion por poblacion

Despues de un cambio importante conviene probar la politica con al menos cuatro perfiles:

un administrador con MFA fuerte
un usuario interno normal sin privilegios
un guest o external user
una cuenta o flujo que antes dependia de un cliente legacy o de una exclusion

La idea no es solo confirmar que el login bloquea o permite, sino comprobar por que lo hace y que control exacto se aplico. Esa diferencia es la que separa una politica documentada de una politica realmente entendida por el equipo.

Referencias primarias

Microsoft Learn: Security defaults in Microsoft Entra ID
Microsoft Learn: Conditional Access policies for guests and external users
Microsoft Learn: Authentication methods policy in Microsoft Entra ID
Microsoft Learn: Authentication strengths in Microsoft Entra Conditional Access
Microsoft Learn: Conditional Access policy templates and report-only mode

Lecturas relacionadas

Lea este articulo junto con la politica de invitados, los metodos de autenticacion permitidos y las exclusiones activas. En acceso condicional Azure, casi todas las brechas serias aparecen en la interseccion entre poblacion, flujo de autenticacion y excepciones que nadie revisa.

Acceso condicional Azure: brechas reales que permiten bypass de MFA