Microsoft 365 es la plataforma más atacada en PYMEs de Centroamérica. La mayoría de las brechas no explotan vulnerabilidades del software — explotan configuraciones incorrectas que se pueden corregir hoy.
La plataforma más usada es también la más atacada
Microsoft 365 está en el centro del trabajo de millones de PYMEs en Centroamérica: correo, documentos, Teams, SharePoint. Es el corazón digital del negocio.
También es el objetivo preferido de los atacantes. No porque tenga más vulnerabilidades que otras plataformas, sino porque es universal — si aprendes a atacar Microsoft 365, puedes atacar a prácticamente cualquier empresa.
La mayoría de las brechas que investigamos en Microsoft 365 no explotan vulnerabilidades del software. Explotan configuraciones incorrectas — opciones que Microsoft dejó como defecto por compatibilidad, pero que representan riesgos reales 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 clienteO verificar via PowerShell:
Get-AuthenticationPolicy | Select-Object Name, AllowBasicAuthSmtp, AllowBasicAuthImap
La 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).
6. Políticas de contraseña que fuerzan cambios periódicos
Forzar cambios de contraseña por calendario lleva a patrones previsibles y reutilización. La línea base debe priorizar frases largas y únicas, bloqueo de contraseñas comprometidas, MFA y cambio inmediato cuando exista evidencia de exposición. Las cuentas de emergencia y de servicio necesitan controles y revisión propios.
7. Acceso a SharePoint desde dispositivos no administrados
Una identidad válida no convierte un dispositivo personal o comprometido en un punto de acceso confiable. Para información sensible, las políticas de Acceso Condicional deben limitar descargas y exigir dispositivos administrados o conformes. Antes de bloquear, inventaríe excepciones, pruebe el impacto y documente un procedimiento de acceso temporal.
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.
¿Necesita convertir estas recomendaciones en responsables, evidencia y un plan verificable? Conozca nuestro servicio de servicios de DevSecOps y seguridad cloud.
Artículos relacionados
Continúe con estas guías del tema nube y microsoft 365.