Modulo 01. Superficie de seguridad en Microsoft 365

Objetivo del modulo

Entender que partes del ecosistema Microsoft 365 concentran mas riesgo y como se relacionan identidad, correo, colaboracion, dispositivos y aplicaciones en un mismo tenant.

Resultados esperados

• Identificar los principales planos de ataque de Microsoft 365.
• Explicar el papel de Entra ID, Exchange Online, SharePoint, Teams, Intune y Defender.
• Priorizar quick wins iniciales de seguridad en un tenant corporativo.

Desarrollo teorico

Microsoft 365 no es solo un paquete de productividad. Es una plataforma de identidades, correo, documentos, colaboracion, administracion de dispositivos y aplicaciones cloud. Cuando un atacante compromete una cuenta de Microsoft 365 no solo obtiene acceso al email; puede heredar acceso a Teams, SharePoint, OneDrive, integraciones SaaS, dispositivos registrados y flujos de negocio. Por eso la superficie de seguridad de un tenant es amplia y esta muy conectada.

El primer plano es identidad. Entra ID autentica usuarios, grupos, aplicaciones empresariales y dispositivos. Una cuenta comprometida puede ser el punto de entrada a todo lo demas. Por eso MFA, conditional access, revision de roles, gobierno de aplicaciones consentidas y proteccion frente a autenticacion heredada son pilares del tenant. Sin identidad segura, el resto de controles pierde fuerza.

El segundo plano es correo y mensajeria. Exchange Online sigue siendo un vector de ataque critico por volumen y por impacto. Phishing, business email compromise, malware en adjuntos, enlaces maliciosos y abuso de buzones son amenazas habituales. Exchange Online Protection y Microsoft Defender for Office 365 aportan antispam, antimalware, Safe Links, Safe Attachments, policies de anti-phishing y capacidades de investigation. Pero estos controles necesitan configuracion y operacion: dominios permitidos, spoof intelligence, reglas de transporte, alertas de reenvio o controles sobre buzones compartidos.

El tercer plano es colaboracion. SharePoint Online, OneDrive y Teams concentran gran parte del dato corporativo y de las interacciones del usuario. Los riesgos mas frecuentes son comparticion externa excesiva, enlaces anonimos, acceso de invitados mal gobernado, proliferacion de teams sin ownership claro, almacenamiento de documentos sensibles sin clasificacion y proliferacion de apps o conectores. En Teams, ademas, correo y colaboracion convergen: un atacante que compromete una cuenta puede moverse por chats, archivos compartidos y reuniones grabadas.

El cuarto plano es dispositivo. Intune y la gestion MDM/MAM permiten decidir si un dispositivo es conforme, si puede acceder a datos corporativos, que apps se protegen y que acciones remotas existen en caso de perdida o baja. Si el tenant permite acceso pleno desde equipos personales sin controles, la fuga de informacion y el robo de sesion son mucho mas probables. Por eso la postura de seguridad del dispositivo y la del usuario deben evaluarse juntas.

El quinto plano es la capa de aplicaciones y automatizaciones. Aplicaciones empresariales con permisos OAuth, Power Automate flows, conectores, apps de Teams o integraciones con terceros amplian funcionalidad, pero tambien crean relaciones de confianza. Un consentimiento excesivo a una app puede dar acceso a correo, archivos o perfiles de usuario sin que el atacante necesite robar la contraseña de nuevo. Revisar apps registradas, permisos granted y service principals no es una tarea opcional en tenants maduros.

Una buena manera de pensar el tenant es como una cadena de confianza que un atacante puede recorrer si encuentra el primer eslabon debil. Un usuario se autentica en Entra ID; su token le abre correo, Teams y SharePoint; sus archivos pueden sincronizarse con OneDrive; su dispositivo puede estar administrado por Intune; sus alertas pueden verse en Microsoft 365 Defender Portal. En terminos de MITRE ATT&CK, el compromiso de una cuenta M365 puede cubrir tacticas como Initial Access (T1566 Phishing), Collection (T1114 Email Collection, T1213 Data from Information Repositories), Persistence (T1098 Account Manipulation para reglas de reenvio o consentimiento de apps) y Exfiltration. Si un atacante obtiene acceso a la identidad y el dispositivo no tiene protecciones adecuadas, puede moverse con gran eficiencia por todo el ecosistema. Por eso Microsoft impulsa un enfoque Zero Trust basado en tres principios: verify explicitly (autenticar y autorizar siempre con todos los datos disponibles), use least privilege (limitar acceso con JIT/JEA y politicas adaptativas) y assume breach (segmentar acceso, verificar cifrado y usar analitica para detectar amenazas).

Desde la perspectiva de la triada CIA, el tenant de Microsoft 365 concentra riesgos en las tres dimensiones. La confidencialidad se ve amenazada por phishing, fuga de datos a traves de sharing o apps maliciosas y exfiltracion desde buzones o SharePoint. La integridad puede verse comprometida si un atacante modifica configuraciones, crea reglas de transporte maliciosas o altera datos en SharePoint. La disponibilidad se ve afectada por ataques de denegacion de servicio, borrado masivo de datos o bloqueo de cuentas. Microsoft Purview ayuda a proteger la confidencialidad e integridad del dato mediante etiquetas de sensibilidad, DLP y retencion, mientras que Microsoft Defender XDR proporciona deteccion y respuesta correlacionada entre identidad, correo, endpoint y cloud apps.

Un ejemplo: una empresa habilita invitados en Teams y SharePoint sin expiracion, no exige MFA para todos los usuarios y permite consentimiento de aplicaciones por defecto. Un atacante envia un correo de phishing con enlace a una pagina falsa de inicio de sesion, roba las credenciales de una cuenta sin MFA y usa el buzon comprometido para localizar documentos financieros en SharePoint. Posteriormente, el atacante solicita consentimiento a una aplicacion OAuth maliciosa que obtiene permisos de lectura sobre Mail.Read y Files.ReadWrite.All, manteniendo acceso persistente incluso si la contraseña se cambia. La cadena completa demuestra que el riesgo no estaba solo en el correo. Estaba en la suma de identidad sin MFA, datos sin clasificacion, gobierno de apps insuficiente y falta de monitorizacion de consentimientos.

Los quick wins iniciales de un tenant suelen ser:

1. MFA para todos los usuarios, con metodos resistentes al phishing (FIDO2) para admins.
2. Bloqueo de autenticacion heredada (protocolos como IMAP, POP3, SMTP basic).
3. Revisar roles privilegiados con PIM y proteger cuentas break-glass.
4. Endurecer comparticion externa y acceso de invitados con expiracion y access reviews.
5. Activar politicas base de anti-phishing y Safe Links/Attachments en Defender for Office 365.
6. Revisar apps OAuth con permisos altos y restringir user consent.
7. Definir politicas de compliance de dispositivos en Intune integradas con conditional access.

Contenido ampliado

Puntos clave

• La identidad es la llave de entrada al resto del tenant.
• Correo y colaboracion forman un ecosistema unico, no controles aislados.
• Dispositivo, identidad y dato deben evaluarse juntos.
• Las apps con permisos OAuth forman parte real de la superficie de ataque.

Checklist operativa

• Inventariar admins, cuentas break-glass y apps empresariales.
• Revisar sharing externo y acceso de invitados.
• Evaluar si existe MFA universal y bloqueo de legacy auth.
• Confirmar que hay politicas base de correo y de compliance de dispositivos.

Errores frecuentes

• Pensar que Microsoft 365 se protege solo por ser SaaS.
• Separar correo, identidad y colaboracion como si no compartieran riesgo.
• Permitir consentimiento de apps sin gobierno.
• No revisar cuentas privilegiadas antiguas o invitados huérfanos.

Practica sugerida

Haz un inventario de riesgos de un tenant ficticio con 500 usuarios y clasificalos por identidad, correo, colaboracion, dispositivos y apps. Prioriza los cinco quick wins mas urgentes.

Preguntas de autoevaluacion

• ¿Por que un robo de cuenta en M365 impacta mucho mas que solo el correo?
• ¿Que elementos del tenant revisarías primero tras un phishing exitoso?
• ¿Que diferencia hay entre un riesgo de sharing externo y uno de apps OAuth?

Cierre

La seguridad de Microsoft 365 empieza entendiendo que el tenant es un sistema integrado. Si identidad, datos, dispositivos y apps se gobiernan por separado, el atacante encontrara huecos.

Modulo 02. Entra ID, MFA y acceso condicional

Objetivo del modulo

Diseñar una linea base de identidad moderna en Microsoft 365 basada en MFA, acceso condicional y gobierno de privilegios.

Resultados esperados

• Diferenciar autenticacion, politicas de acceso condicional y proteccion de identidad.
• Explicar cuando usar MFA, passwordless, PIM y cuentas de emergencia.
• Detectar errores comunes en roles privilegiados y excepciones de acceso.

Desarrollo teorico

En Microsoft 365, Entra ID actua como plano central de autenticacion y autorizacion, funcionando como el Identity Provider (IdP) del que depende todo el ecosistema. Cualquier usuario, administrador, dispositivo registrado o aplicacion conectada acaba dependiendo de esta capa. Desde la perspectiva de MITRE ATT&CK, la identidad es el vector mas frecuente de acceso inicial a entornos M365: tecnicas como T1566 Phishing, T1110 Brute Force (password spray) y T1078 Valid Accounts dominan las intrusiones. Por eso una baseline sana empieza aqui. El primer control es MFA universal, con prioridad absoluta para administradores, acceso remoto y aplicaciones sensibles. Hoy no basta con "recomendar" MFA; debe exigirse mediante Conditional Access y medirse su cobertura real con metricas verificables (porcentaje de usuarios con MFA registrado y activo).

MFA no elimina todo el riesgo de identidad. Existen ataques de fatiga MFA (bombardeo de notificaciones push hasta que el usuario acepta), phishing proxy con herramientas como Evilginx2 que capturan cookies de sesion en tiempo real (T1557 Adversary-in-the-Middle), y robo de token desde endpoints comprometidos. Por eso Microsoft combina autenticacion fuerte con Conditional Access, Identity Protection y controles de sesion. Conditional Access permite expresar condiciones de acceso granulares: si el usuario entra desde una ubicacion no confiable, si el dispositivo no cumple compliance (Intune), si la aplicacion objetivo es sensible (por ejemplo, Azure Portal o Exchange Online) o si Identity Protection detecta riesgo alto de inicio de sesion, entonces el sistema puede requerir MFA, bloquear el acceso o restringir la sesion (por ejemplo, sin descarga de archivos en SharePoint). La potencia real esta en combinar multiples señales de contexto, no en crear reglas aisladas sin un diseño coherente.

Un baseline comun de Conditional Access incluye:

1. MFA para todos los usuarios, con metodos resistentes al phishing (FIDO2, Windows Hello) para administradores.
2. Politicas separadas para admins (mayor restriccion), usuarios estandar e invitados.
3. Bloqueo de autenticacion heredada (IMAP, POP3, SMTP Auth, ActiveSync basic) que no soporta MFA y es vector habitual de password spray.
4. Exigir dispositivo conforme (managed por Intune) o app aprobada (app protection policy) para acceso a datos sensibles en SharePoint, OneDrive y Exchange.
5. Limitar ubicaciones de confianza a named locations verificadas y revisar excepciones.
6. Integrar Identity Protection para responder automaticamente a riesgo de usuario (forzar cambio de contraseña) o riesgo de sign-in (requerir MFA adicional).

Los privilegios requieren un tratamiento especial dentro de la triada CIA, ya que una cuenta privilegiada comprometida puede impactar las tres dimensiones: acceder a datos confidenciales (confidencialidad), modificar configuraciones criticas del tenant (integridad) y borrar recursos o deshabilitar servicios (disponibilidad). Los roles como Global Administrator, Privileged Role Administrator, Exchange Administrator o SharePoint Administrator deben ser pocos, separados del uso diario y gestionados con Privileged Identity Management (PIM). PIM permite elevacion just-in-time con aprobaciones obligatorias, notificaciones, expiracion de acceso y auditoria completa de activaciones. Eso reduce drasticamente el tiempo durante el que una cuenta permanece con privilegios altos, alineandose con el principio de minimo privilegio y reduce la ventana de oportunidad para un atacante. Microsoft recomienda un maximo de dos a cuatro Global Administrators permanentes, y el resto deben ser eligible con activacion temporal.

Las cuentas de emergencia o break-glass son necesarias para garantizar acceso al tenant en caso de fallo de MFA, del IdP federado o de un bloqueo masivo por Conditional Access mal configurado. Deben ser excepcionales: exactamente dos cuentas, excluidas de ciertas politicas, protegidas con contraseñas complejas custodiadas en caja fuerte fisica o vault seguro, y monitorizadas con alertas especificas en el SIEM que notifiquen cualquier inicio de sesion. Un error grave es usarlas como cuentas de operacion diaria o dejarlas sin revisar durante años.

Otra pieza importante es el gobierno de aplicaciones (app governance). Entra ID almacena enterprise applications, app registrations y consentimientos OAuth. Si cualquier usuario puede consentir permisos altos sin supervision, una aplicacion maliciosa puede obtener permisos como Mail.Read, Files.ReadWrite.All o User.ReadWrite.All sobre el correo, calendario o archivos del usuario sin necesidad de robar la contraseña de nuevo (T1098.003 Additional Cloud Credentials). Conviene configurar la politica de user consent para que solo se permitan permisos de bajo impacto verificados por el publisher, implementar admin consent workflow para permisos elevados, y revisar periodicamente el listado de aplicaciones con permisos Graph elevados en el tenant.

En entornos hibridos donde Entra ID se sincroniza con Active Directory on-premises mediante Entra Connect (anteriormente Azure AD Connect), la seguridad del tenant depende tambien de la seguridad del AD local. Password hash sync, pass-through authentication o federation tienen implicaciones distintas de seguridad. Un compromiso del servidor Entra Connect o del controlador de dominio puede proyectarse directamente al tenant cloud, permitiendo al atacante crear Golden SAML tokens o sincronizar credenciales comprometidas. Lo importante es entender que las identidades privilegiadas deben gobernarse de forma coherente en ambos lados: cuentas separadas, MFA, monitorizacion de cambios de membresia en grupos privilegiados y alertas sobre actividad anomala tanto en AD on-prem como en Entra ID.

Contenido ampliado

Puntos clave

• MFA es obligatorio, pero no suficiente por sí solo.
• Conditional Access aporta contexto y convierte Zero Trust en política operativa.
• PIM reduce exposición de privilegios altos.
• Las apps consentidas son parte de la identidad del tenant.

Checklist operativa

• Revisar cobertura MFA por usuario y por rol.
• Confirmar bloqueo de legacy authentication.
• Auditar admins permanentes y valorar PIM.
• Revisar políticas de consentimiento de aplicaciones.

Errores frecuentes

• Tener muchas exclusiones “temporales” de MFA.
• Crear demasiadas políticas de acceso condicional sin orden.
• Mantener admins globales para tareas que no lo necesitan.
• No monitorizar cuentas de emergencia.

Practica sugerida

Diseña una baseline de Entra ID para una empresa de 300 usuarios con tres sedes y teletrabajo. Incluye MFA, políticas de acceso condicional y estrategia para roles privilegiados.

Preguntas de autoevaluacion

• ¿Por qué bloquear legacy auth es tan importante?
• ¿Qué diferencia hay entre MFA universal y acceso condicional bien diseñado?
• ¿Qué riesgos introduce dejar el consentimiento de apps demasiado abierto?

Cierre

Entra ID es el punto de control más importante de Microsoft 365. Cuando identidad y privilegios se gobiernan bien, el resto del tenant parte de una posición mucho más fuerte.