Hardening M365 más allá del baseline: lo que el Defender Score no te cuenta

El problema con el Defender Score

Llegar al 75% en Defender Score cuando la media de organizaciones de tamaño similar ronda el 45% es un logro real. Significa que alguien ha dedicado tiempo y criterio a la configuración. Pero ese número tiene un problema estructural: mide lo que Microsoft ha decidido incluir en su checklist, no todos los vectores de ataque relevantes en producción.

La situación más ilustrativa es la del flujo de autenticación por código de dispositivo. Un administrador lo descubre casi por accidente, lo bloquea, y luego comprueba que no aparece en ninguna lista oficial de hardening de Microsoft. Estaba activo por defecto. Y es uno de los vectores de entrada más utilizados en ataques BEC sofisticados.

Ese tipo de brecha —visible solo si sabes que existe— es exactamente de lo que trata este artículo.

Por qué los defaults de Entra son un problema real

Hay una crítica recurrente entre quienes administran entornos M365 en producción: los valores por defecto de Entra ID permiten cosas que no deberían estar activas en ningún entorno empresarial. No es exageración. Es la experiencia directa de equipos que han tenido que responder a incidentes y han rastreado el origen hasta una configuración que nadie tocó porque venía habilitada de fábrica.

Uno de los más peligrosos: el consentimiento de aplicaciones por parte de usuarios. Por defecto, cualquier usuario puede autorizar que una aplicación externa acceda a sus datos de Microsoft 365. Si alguien cae en un ataque de phishing de consentimiento OAuth —una página que simula ser una app legítima y solicita permisos— el atacante obtiene un token de acceso que sobrevive tanto al reseteo de contraseña como al MFA. No hay forma de bloquearlo una vez concedido, salvo revocar explícitamente el consentimiento.

Otro detalle que sorprende a muchos: cuando Microsoft activa su opción de Baseline Security, puede revertir restricciones de consentimiento que habías configurado manualmente, permitiendo de nuevo apps certificadas sin aprobación. Es un comportamiento que requiere auditoría activa, no solo configuración inicial.

Los tres vectores que más daño hacen en entornos reales

1. Flujo de autenticación por código de dispositivo

Este flujo existe para autenticar dispositivos sin navegador (impresoras, televisores, entornos CLI). En un entorno de oficina con usuarios en portátiles y móviles, su utilidad es prácticamente nula. Sin embargo, es el vector de entrada preferido en ataques BEC modernos porque permite engañar al usuario para que introduzca un código en una página legítima de Microsoft, sin que el atacante necesite la contraseña.

Lo que hace especialmente peligroso este vector es la combinación con proxies residenciales de la región del usuario: el acceso parece provenir de una IP local conocida, lo que evade muchos controles geográficos y de riesgo. La persistencia obtenida a través de este flujo puede mantenerse durante semanas si no hay monitorización activa.

Acción concreta: bloquear el flujo de autenticación por código de dispositivo desde las Políticas de Acceso Condicional, creando una política que lo deniegue para todos los usuarios salvo excepciones documentadas y justificadas.

2. Consentimiento de aplicaciones OAuth sin control admin

La cadena de ataque de phishing de consentimiento es elegante en su simplicidad: el usuario hace clic en un enlace, autoriza una app aparentemente legítima, y el atacante tiene un token con permisos sobre su buzón, calendario y archivos. Sin contraseña robada. Sin MFA que sirva de barrera.

Acción concreta: en Entra ID, ir a Enterprise Applications, sección Consent and permissions, opción User consent settings. Configurar para que solo los administradores puedan dar consentimiento, o al menos para que los scopes de alto riesgo requieran aprobación explícita de admin. Revisar periódicamente las apps que ya tienen consentimiento concedido.

3. Protocolos legacy en Exchange

SMTP autenticado, IMAP y POP son protocolos que no soportan autenticación moderna ni MFA. Si están activos, cualquier atacante con unas credenciales válidas puede autenticarse directamente, saltándose por completo todas las políticas de Acceso Condicional. Son una puerta trasera que muchos entornos tienen abierta sin saberlo.

Acción concreta: deshabilitar autenticación básica para estos protocolos a nivel de organización en Exchange Online. Antes de hacerlo, auditar qué cuentas o sistemas los usan actualmente para no cortar operativa legítima (líneas de impresoras, sistemas de alertas, integraciones antiguas).

Conditional Access: la palanca que transforma M365

Las Políticas de Acceso Condicional son la herramienta más potente del ecosistema M365 para reducir superficie de ataque, y no requieren licencias adicionales en la mayoría de configuraciones relevantes. El reto real es implementarlas sin bloquear operativa legítima.

Plan de implementación sin cortar servicio

El error más común es desplegar políticas en modo activo desde el primer día. El proceso correcto tiene tres fases:

• Fase 1 — Auditoría previa: antes de crear ninguna política, revisar en los logs de inicio de sesión de Entra qué países, dispositivos y aplicaciones generan autenticaciones legítimas. Esto define el mapa de lo que hay que permitir.
• Fase 2 — Modo solo informe: crear las políticas en modo Report-only durante dos semanas. Entra muestra qué usuarios habrían sido bloqueados sin aplicar el bloqueo real. Permite identificar casos excepcionales: el proveedor externo que accede desde otro país, el directivo con un dispositivo personal no registrado, la cuenta de servicio que usa un protocolo legacy.
• Fase 3 — Activación progresiva: activar primero las políticas de menor riesgo de interrupción (bloqueo de geografías claramente fuera del negocio), luego las de dispositivos registrados, y finalmente las más restrictivas. Mantener siempre una cuenta break-glass excluida de todas las políticas para emergencias.

Para entornos con teletrabajo y VPN, la recomendación práctica es combinar el requisito de dispositivo inscrito en Intune con un certificado de cliente, de modo que el acceso desde fuera de oficina exija tanto identidad verificada como dispositivo corporativo gestionado. Esto convierte efectivamente M365 en un servicio de acceso controlado, equivalente en práctica a tener el servidor solo en la LAN local.

Para proveedores externos que necesitan acceso puntual, lo correcto es crear cuentas de invitado con permisos mínimos y políticas específicas, no hacer excepciones en las políticas generales.

Configuraciones adicionales que complementan Conditional Access

• Restringir el acceso a SharePoint solo desde dominios registrados y dispositivos gestionados.
• Revisar y limitar los ajustes de uso compartido con invitados en Entra: el tipo de compartición por defecto es editable, no solo lectura, lo que implica que un enlace compartido con un externo le da permisos de modificación por defecto.
• Limitar los ajustes de invitados a nivel de tenant para controlar quién puede invitar usuarios externos y con qué permisos.
• Configurar que el acceso al correo solo sea posible desde Outlook o webmail en equipos inscritos en Intune, y que el relay de correo externo solo esté permitido desde el SEG corporativo.

Marcos de referencia que funcionan en la práctica

Una de las frustraciones más habituales al buscar información sobre hardening M365 es encontrar documentación desactualizada o guías genéricas que no se ajustan a la realidad de un entorno en producción. Hay dos referencias que la comunidad técnica considera sólidas y actualizadas:

• CIS Benchmark para Microsoft 365: organiza los controles por categorías con instrucciones paso a paso. Es especialmente útil para mapear la situación actual de una organización de forma sistemática. Para un entorno de entre 50 y 200 usuarios, el enfoque práctico es trabajar por niveles: empezar con los controles de nivel 1 (impacto alto, complejidad baja) antes de abordar los de nivel 2.
• SCUBA de CISA: la herramienta de evaluación automatizada de la agencia americana de ciberseguridad cubre controles específicos del ecosistema Microsoft y genera informes accionables. Combinada con la herramienta de evaluación Zero Trust de Microsoft, ofrece una visión completa de gaps reales versus gaps de documentación.

La diferencia entre usar estas referencias y buscar de forma ad hoc es sistemática: en vez de cerrar brechas que vas descubriendo por accidente, trabajas contra un mapa completo de controles conocidos.

Auditoría continua: lo que hay que monitorizar activamente

La configuración inicial es necesaria pero no suficiente. Entra ID y Exchange Online cambian con frecuencia, y actualizaciones de Microsoft pueden modificar comportamientos que habías configurado explícitamente. La auditoría tiene que ser continua.

En cuanto a herramientas, Maester.dev —creada por un ex-responsable de producto de Entra— es actualmente la referencia más completa para auditoría automatizada y continua de entornos M365. Ejecuta tests contra la configuración del tenant y detecta desviaciones respecto a los controles de CIS, CISA y otros marcos. Su newsletter semanal es además un recurso valioso para estar al día con los cambios continuos en Entra, que son más frecuentes de lo que la documentación oficial refleja.

Las alertas que no deberían faltar en ningún entorno:

• Inicio de sesión con flujo de código de dispositivo (debería ser cero si está bloqueado correctamente).
• Nuevos consentimientos de aplicaciones concedidos, especialmente fuera de horario laboral.
• Autenticaciones mediante protocolos legacy que deberían estar deshabilitados.
• Cambios en políticas de Acceso Condicional o en configuración de consentimiento de apps.
• Inicios de sesión desde geografías bloqueadas, aunque resulten en denegación (son intentos reales de acceso).
• Cambios en roles de administrador global o privilegiado.

Todas estas alertas se pueden configurar desde el portal de Entra ID combinando los logs de auditoría con reglas en Microsoft Sentinel o, para entornos más pequeños, con alertas nativas en Defender for Cloud Apps si se dispone de la licencia correspondiente.

La dirección hacia la que va esto: FIDO2 y autenticación sin contraseña

Cada vez más equipos técnicos están evaluando o implementando llaves FIDO2 para eliminar la contraseña del flujo de autenticación en M365. Es el escenario donde device code phishing y credential stuffing dejan de ser vectores viables, porque no hay contraseña que robar ni flujo de código que interceptar.

No es una solución inmediata para todos los entornos, pero es la dirección técnica correcta. La combinación de Conditional Access bien configurado, restricción de consentimiento OAuth y bloqueo de protocolos legacy es el camino que prepara el terreno para llegar ahí con una superficie de ataque ya reducida.

Lo que todo esto significa en términos reales

Un ataque BEC exitoso no es solo un problema técnico. Es una transferencia bancaria redirigida, una notificación de brecha bajo RGPD, y un daño de reputación con clientes y proveedores que puede tardar años en recuperarse. El coste real de un incidente de este tipo supera con claridad el tiempo invertido en configurar correctamente Conditional Access y revisar los defaults de Entra.

La mayoría de estas configuraciones no requieren licencias adicionales: requieren conocimiento, criterio y un proceso de auditoría que no termine el día que termina la implantación inicial.

Vale la pena revisar qué flujos de autenticación tiene activos tu tenant ahora mismo. Probablemente haya algo que debería estar bloqueado y no lo está.