Microsoft 365 es la plataforma más usada en empresas — y uno de los vectores de ataque más activos. Estas configuraciones están mal configuradas en la mayoría de PYMEs y son lo primero que los atacantes verifican.
Su empresa usa Outlook, Teams, SharePoint y OneDrive. Probablemente también Exchange Online, quizás Intune. Microsoft 365 se ha convertido en la columna vertebral operativa de millones de organizaciones en el mundo, incluyendo la gran mayoría de empresas medianas de Centroamérica.
Esa ubicuidad lo convierte en el objetivo más valioso para los atacantes. En 2024, Microsoft reportó que su plataforma bloqueó más de 600 millones de ataques al día contra identidades de M365. Esos son los ataques que Microsoft detectó y bloqueó. Los que pasan son los que preocupan.
La buena noticia es que la mayoría de las brechas exitosas en M365 no explotan vulnerabilidades de software: explotan configuraciones incorrectas que los administradores establecieron (o dejaron por defecto) sin comprender las implicaciones de seguridad.
1. Autenticación heredada habilitada (Legacy Authentication)
Este es, consistentemente, el hallazgo más común y más peligroso en cualquier auditoría de M365. Los protocolos de autenticación heredada —SMTP AUTH, POP3, IMAP, Exchange ActiveSync versiones antiguas— fueron diseñados antes de que existiera la autenticación multifactor. Por definición, no soportan MFA.
Esto significa que si un atacante obtiene el usuario y la contraseña de alguien en su organización —a través de phishing, de una filtración de datos, o simplemente porque la persona usa la misma contraseña en otro servicio comprometido— puede acceder al correo corporativo directamente usando IMAP o SMTP AUTH, saltándose por completo el segundo factor de autenticación que tanto trabajo costó implementar.
Los grupos de amenaza avanzada utilizan herramientas automatizadas que prueban credenciales filtradas contra miles de tenants de M365 buscando específicamente estos protocolos abiertos. El ataque se llama password spray y es silencioso: en lugar de probar miles de contraseñas contra una cuenta (lo que dispara alertas de bloqueo), prueban una sola contraseña contra miles de cuentas.
Cómo verificarlo y solucionarlo:
# En Azure AD / Entra ID → Seguridad → Acceso Condicional
# Crear una política que bloquee "Otros clientes" en la condición de aplicaciones cliente
# O verificar via PowerShell:
Get-AuthenticationPolicy | Select-Object Name, AllowBasicAuthSmtp, AllowBasicAuthImapLa solución definitiva es crear una Política de Acceso Condicional en Entra ID que bloquee todos los flujos de autenticación heredada para todos los usuarios. Microsoft tiene una plantilla pre-configurada llamada "Bloquear autenticación heredada" disponible en el portal.
2. MFA no obligatorio para todos los usuarios
La autenticación multifactor bloquea el 99,9% de los ataques de compromiso de cuenta, según datos de Microsoft. Sin embargo, en muchas organizaciones MFA es opcional o solo está habilitado para administradores.
El error más común no es no tener MFA: es tenerlo implementado de forma incompleta. Encontramos con frecuencia tenants donde MFA está habilitado para las cuentas del equipo de TI, pero donde el CEO, el CFO o las cuentas de servicio —precisamente las más valiosas para un atacante— no lo tienen.
También existe el problema de los Defaults de Seguridad de Microsoft. Los tenants más antiguos fueron migrados sin estos defaults habilitados, y muchos nunca se actualizaron. Si su tenant de M365 fue creado antes de octubre de 2019 y nadie ha revisado explícitamente la configuración de MFA, existe una probabilidad real de que no esté activa.
Verificación rápida: En el portal de Entra ID, vaya a Propiedades → Administrar valores predeterminados de seguridad. Si está desactivado, revise si tiene Acceso Condicional como reemplazo. Si tampoco hay políticas de Acceso Condicional que fuercen MFA, tiene una exposición crítica.
3. Consentimiento OAuth a aplicaciones de terceros sin control
Este vector de ataque se conoce como Illicit Consent Grant y es elegante en su peligrosidad: el atacante no roba contraseñas. Le pide al usuario que le dé acceso voluntariamente.
Funciona así: el atacante crea una aplicación maliciosa registrada en Azure AD que solicita permisos aparentemente razonables —"leer su correo" o "acceder a sus archivos"— a través de una ventana de consentimiento OAuth con el logo de Microsoft. El usuario, pensando que es una aplicación legítima, hace clic en "Aceptar". La aplicación recibe un token de OAuth que le da acceso permanente al correo y los archivos del usuario, incluso si este cambia su contraseña.
El FBI emitió una alerta específica sobre esta técnica en 2022 después de que múltiples organizaciones del sector financiero la sufrieran. La solución no es técnicamente compleja:
- En Entra ID → Aplicaciones empresariales → Configuración de consentimiento del usuario: cambiar a "No permitir el consentimiento del usuario".
- Crear un flujo de aprobación de administrador para que los usuarios puedan solicitar acceso a aplicaciones legítimas sin otorgarlo directamente.
- Revisar aplicaciones con consentimiento existente en el portal de Entra ID y revocar las que no reconozca.
4. Reglas de reenvío automático de correo hacia dominios externos
Cuando un atacante obtiene acceso a una cuenta de correo corporativa, una de sus primeras acciones es configurar una regla de reenvío automático hacia su propia dirección. Así recibe copias de todos los correos futuros —incluyendo contratos, facturas y comunicaciones confidenciales— incluso después de que la contraseña sea cambiada y el acceso directo se pierda.
Sorprendentemente, el reenvío automático hacia dominios externos está habilitado por defecto en Microsoft 365. Cualquier usuario puede configurarlo desde Outlook. Muchas organizaciones no lo descubren hasta meses después, durante una auditoría o cuando un cliente reporta haber recibido comunicaciones fraudulentas.
Solución: En el Exchange Admin Center, crear una política de transporte (Transport Rule) que bloquee el reenvío automático hacia dominios externos. También puede configurarse desde el portal de Defender for Office 365 en la sección de políticas anti-spam.
# Verificar si hay reglas de reenvío activas en la organización
Get-Mailbox -ResultSize Unlimited |
Get-MailboxAutoReplyConfiguration |
Where-Object {$_.ExternalAudience -ne "None"}5. SharePoint y OneDrive: el problema del sobrecompartir
SharePoint Online y OneDrive permiten compartir archivos con "cualquier persona con el enlace". Esta función, diseñada para facilitar la colaboración, se convierte en un riesgo cuando se aplica a documentos sensibles: contratos, estados financieros, datos de clientes, credenciales.
En auditorías de M365, encontramos regularmente organizaciones donde cientos o miles de documentos están compartidos públicamente sin que ningún administrador lo sepa. Los empleados los compartieron porque era conveniente, y el enlace quedó activo indefinidamente.
La configuración correcta tiene dos componentes:
- Nivel de organización: En el SharePoint Admin Center, cambiar el nivel predeterminado de uso compartido externo a "Solo personas de su organización" o "Invitados existentes" como máximo.
- Expiración de enlaces: Configurar que los enlaces de uso compartido externo expiren automáticamente (30 días es un buen punto de partida).
Tres configuraciones adicionales que marcan la diferencia
Más allá de las cinco principales, hay configuraciones que sistemáticamente encontramos incorrectas en PYMEs:
- Roles de administrador global sobreasignados: En un tenant sano, el número de administradores globales debe ser mínimo (2-4 cuentas de emergencia). Encontramos tenants donde el 20-30% del equipo técnico tiene ese rol por conveniencia.
- Alertas de inicio de sesión sospechoso no configuradas: Microsoft Identity Protection puede generar alertas automáticas ante inicios de sesión desde ubicaciones inusuales, viajes imposibles o dispositivos no reconocidos. Muchas organizaciones no las tienen habilitadas.
- Auditoría de M365 desactivada: El registro unificado de auditoría es la fuente principal de evidencia forense en caso de incidente. En planes básicos de M365, puede no estar habilitado por defecto.
Microsoft Secure Score: su línea base
Microsoft proporciona una herramienta gratuita dentro del portal de Defender llamada Secure Score. Analiza la configuración de su tenant y le da un puntaje de 0 a 100, comparado contra el promedio de organizaciones similares. Cada recomendación incluye el impacto estimado en puntos y las instrucciones para implementarla.
Si no ha revisado su Secure Score, acceda en security.microsoft.com → Secure Score. Un puntaje por debajo de 40 en el componente de Identidad indica exposición significativa que requiere atención inmediata.
En el siguiente artículo de la serie subimos a la capa de infraestructura cloud: Azure y las misconfiguraciones que convierten recursos de nube en puertas abiertas para cualquiera que sepa dónde buscar.
¿No sabe cuál es su Secure Score actual o cómo interpretar las recomendaciones? En Structa Defense hacemos revisiones de configuración de M365 como parte de nuestro servicio de Virtual CISO, con un informe priorizado de hallazgos y acompañamiento en la remediación.