La caída de Microsoft 365 alcanzó también a Defender, Intune y Purview: qué revisar al recuperar el servicio

Artículo en actualización. La incidencia seguía abierta cuando se escribió. En los próximos días ampliaremos la información sobre su impacto en los servicios de seguridad de Microsoft 365, a medida que Microsoft publique su informe posterior al incidente.

Durante las horas en que Microsoft 365 dejó sin correo a miles de usuarios, la misma plataforma tampoco podía garantizar que ese correo se analizara, que los dispositivos fueran de fiar ni que las reglas sobre datos sensibles se aplicaran. En muchas organizaciones, entregar el correo, analizarlo, decidir qué equipo es de confianza y vigilar los datos dependen del mismo proveedor.

Empezó en la tarde del 12, hora peninsular, con problemas para acceder a los buzones de Exchange Online en América (incidencia EX1550543). Minutos después, una segunda incidencia, MO1550821, advertía de que usuarios de cualquier región podían no conectarse a varios servicios. La ficha que reproduce la Universidad de Pensilvania enumera Exchange Online, Teams, SharePoint Online, Microsoft 365 Copilot y Microsoft Defender XDR, igual que SecurityWeek.

Las actualizaciones posteriores, según recogen WindowsForum y Cyber Security News, añadieron Defender for Office 365, Intune y varias funciones de Microsoft Purview, entre ellas la prevención de fuga de datos y el etiquetado automático. A media mañana del 13, hora peninsular, Microsoft aún no daba por completada la recuperación.

Microsoft descarta por ahora un ataque: un portavoz dijo a ABC News Australia que no había indicios de ciberataque, y el ministro del Interior australiano, Tony Burke, lo repitió tras reunirse con la compañía. Pero un fallo de disponibilidad deja unas horas en las que la organización ve menos y controla menos, y esas horas hay que revisarlas como un incidente de seguridad.

¿Qué se sabe de la causa?

Se sabe poco, y todo es provisional. Microsoft habló primero de carga elevada en varias regiones y lo corrigió después en su cuenta de estado: el tráfico no había crecido, sino que varios servidores habían dejado de estar disponibles y el resto soportaba su carga. Esos servidores no superaban las comprobaciones automáticas de estado; SecurityWeek añade que Microsoft probaba a sortear el componente que las procesa e investigaba un uso elevado de procesador.

Reiniciar servidores, desviar tráfico y congelar despliegues y cambios de configuración no bastó. Microsoft escribió después que un proceso central de los servidores afectados se estaba desbordando. El 13 de noviembre, según ABC News Australia, afirmó haber acotado el problema y estar revirtiendo un cambio de red reciente, y poco después reconocía que algunos servidores recuperados volvían a dejar de responder al recibir tráfico.

Microsoft suele detallar la causa raíz en el informe posterior al incidente que publica en el centro de administración de Microsoft 365.

¿Hasta dónde llegó el fallo en las capas de seguridad?

Hay que separar tres capas, porque el riesgo es distinto en cada una.

Prevención en el equipo

El antivirus, las reglas de reducción de la superficie de ataque y la protección de red de Microsoft Defender for Endpoint se aplican en el dispositivo con la configuración que ya tenía. Nada de lo publicado indica que dejaran de funcionar. Lo que no se sabe es si siguieron disponibles la protección en la nube, el envío de telemetría y la correlación de alertas en Defender XDR.

Filtrado del correo

Exchange Online Protection filtra en línea, antes de entregar. Ante una caída, es más probable que el correo se retrase o se rechace que que se entregue sin analizar. Defender for Office 365 figura entre los afectados, pero Microsoft no ha detallado si se vieron afectados el análisis de adjuntos y enlaces o solo la consola.

Identidad y dispositivos

Entra ID no aparece en las listas de servicios afectados que recoge la transcripción de los avisos de estado de ENow, y los avisos hablan de fallos de conexión con los servicios, no de autenticación. No consta, por tanto, que el inicio de sesión, el acceso condicional o la autenticación multifactor (MFA) se vieran afectados.

Con Intune el efecto es otro. El acceso condicional no consulta a Intune en cada inicio de sesión: lee el estado de cumplimiento que Intune deja anotado en la ficha del dispositivo en Entra ID. Si Intune no evalúa, se conserva el último estado conocido hasta que vence el periodo de validez del cumplimiento, 30 días por defecto. Un bloqueo masivo es poco probable. El riesgo real es que se siguiera dando acceso a dispositivos que dejaron de ser conformes durante la ventana (por ejemplo, por una señal de riesgo de Defender for Endpoint) y que fallaran las altas de equipos nuevos.

¿Por dónde empezar la revisión cuando vuelva el servicio?

Trate el periodo afectado (la «ventana», en adelante) como un tramo sin cobertura de detección en la nube hasta que el informe de Microsoft diga lo contrario. Delimítelo con el historial de estado de servicio de su inquilino (tenant), que se exporta con la API de Microsoft Graph: en UTC, desde el primer aviso hasta la recuperación confirmada en su región.

Detecciones que ninguna regla evaluó

Es un punto fácil de pasar por alto. En Microsoft Sentinel, las reglas programadas buscan eventos por su hora de generación (TimeGenerated) dentro de su intervalo de búsqueda; un evento que llega con más retraso que ese intervalo no lo evalúa ninguna ejecución. Las reglas casi en tiempo real (NRT) trabajan por la hora de llegada del dato y lo sufren menos. La consulta siguiente mide ese retraso; el percentil 95 indica cuánto tardó en llegar la mayoría de los eventos. Retraso por tabla y franja horaria (UTC; ajuste la hora de inicio al primer aviso de su inquilino):

union DeviceProcessEvents, EmailEvents, IdentityLogonEvents | where TimeGenerated between (datetime(2026-11-12 16:00) .. now()) | extend Retraso = ingestion_time() - TimeGenerated | summarize Eventos = count(), RetrasoP95 = percentile(Retraso, 95) by Type, bin(TimeGenerated, 1h) | order by Type asc, TimeGenerated asc

Compare el volumen con las mismas horas de la semana anterior: pocos eventos solo significan algo frente a esa referencia. Después, relance a mano sobre la ventana completa las reglas críticas cuyo intervalo de búsqueda sea más corto que el retraso medido. Un SIEM con telemetría ajena a Microsoft da el contraste: salidas del proxy hacia dominios nuevos o conexiones del cortafuegos sobre las que Defender no generó alerta.

Correo entregado, retenido o perdido

Cruce EmailEvents con EmailPostDeliveryEvents para ver qué se entregó en la ventana, con qué veredicto y si una acción posterior lo retiró.

La purga automática posterior a la entrega (ZAP) está activa por defecto para malware y suplantación de identidad (phishing), pero solo actúa durante las 48 horas siguientes a la entrega: compruebe que actuó y corrija a mano desde el explorador de amenazas lo que quede fuera de ese plazo. Revise también UrlClickEvents para los clics en enlaces durante la ventana y el seguimiento de mensajes para los avisos de no entrega y los mensajes caducados en cola. Hay correo legítimo que no llegó, y los falsos avisos de no entrega pueden servir de señuelo.

Datos que salieron sin control

La prevención de fuga de datos (DLP) en el correo no se aplica de forma retroactiva, y el explorador de actividad de Purview solo muestra eventos que sí ocurrieron: si la DLP no evaluó, allí no hay nada que ver. La revisión se hace con el registro de auditoría (enlaces compartidos, enlaces anónimos creados) y con EmailEvents y EmailAttachmentInfo filtrando por destinatarios externos, empezando por los usuarios que manejan la información más sensible.

Inicios de sesión y auditoría de Entra ID

Revise los registros de inicio de sesión y de auditoría de Entra ID (registros de nuevos métodos de autenticación, consentimientos a aplicaciones) y las detecciones de riesgo de Identity Protection de la ventana. Ante una cuenta sospechosa, revoque sus sesiones: con la evaluación continua de acceso (CAE), los tokens pueden seguir siendo válidos hasta 28 horas.

Cambios hechos con prisa

Durante una caída larga se toman decisiones rápidas: reenvíos a cuentas personales, exclusiones en el acceso condicional, directivas desactivadas para desbloquear a alguien. Busque en el registro de auditoría unificado New-InboxRule, Set-InboxRule y Set-Mailbox con ForwardingSmtpAddress, y los cambios de acceso condicional; los de Intune están en el registro de auditoría de Intune. La latencia de la auditoría no está garantizada y Microsoft no ha dicho si su canal se vio afectado, así que repita las búsquedas a las 24 y 48 horas. Cada excepción debe tener un responsable y una fecha de reversión.

Fraude que aprovecha la caída

ING avisó a sus clientes de estafadores que usaban la incidencia como gancho, según ABC News Australia. Los mensajes que piden «volver a iniciar sesión», las llamadas de un supuesto soporte y las peticiones urgentes de cambio de contraseña son el phishing previsible estos días. SecurityWeek recuerda además que la actualización mensual de seguridad de Microsoft (Patch Tuesday), dos días antes, corrigió un fallo de suplantación de remitente (spoofing) en Outlook que Microsoft da por explotado; no lo relaciona con la caída, pero es motivo para confirmar que el parche está desplegado. Recuerde al servicio de atención a usuarios que no debe restablecer credenciales por teléfono sin verificar la identidad.

¿Obliga a notificar algo una caída del proveedor?

Puede obligar aunque no haya atacante. Cada entidad lo decide según el impacto que haya sufrido, y el mismo fallo puede ser grave en una y no en otra.

En el sector financiero, DORA clasifica los incidentes relacionados con las TIC por su efecto, sea cual sea su origen, y la entidad sigue siendo responsable aunque el fallo sea del proveedor. Según el Reglamento Delegado 2024/1772, un incidente es grave si afecta a servicios críticos y supera al menos dos umbrales de importancia. Dos de ellos encajan con una caída así: la duración (más de 24 horas de incidente, o más de 2 horas sin un servicio TIC que sustente funciones críticas o importantes) y la pérdida de datos, que incluye su indisponibilidad.

Si el incidente es grave, la notificación inicial debe enviarse en las cuatro horas siguientes a clasificarlo y, como máximo, 24 horas después de tener conocimiento de él; el informe intermedio, a las 72 horas, y el final, al mes. En España se notifica al Banco de España, la CNMV o la DGSFP, según la entidad, y hay que informar a los clientes si se ven afectados sus intereses financieros.

Microsoft figura desde el 18 de noviembre de 2025 entre los 19 proveedores terceros críticos de TIC designados por las autoridades europeas de supervisión. Esa designación somete a Microsoft a supervisión directa y no exime de su responsabilidad a la entidad financiera.

En su informe sobre 2025, esas autoridades contabilizaron 3.383 incidentes graves notificados bajo DORA; alrededor del 29 % se debió a un fallo de un proveedor TIC y solo el 10 % estuvo relacionado con la ciberseguridad. El mismo informe advierte de que un único fallo de un proveedor grande puede generar decenas de incidentes graves relacionados.

Fuera del sector financiero (dentro de él prevalece DORA), NIS2 incluye en su definición de incidente los sucesos que comprometen la disponibilidad y, si el incidente es significativo, exige alerta temprana en 24 horas, notificación en 72 y un informe final en un mes.

En España la ley de transposición sigue pendiente, como explicamos en qué hacer con NIS2 mientras falta la ley española. El ENS, en cambio, está en vigor: el sector público y sus proveedores deben notificar al CCN-CERT los incidentes con impacto significativo, y la disponibilidad es una de sus dimensiones de seguridad. Si hubo datos personales inaccesibles, procede además valorar si es una violación de seguridad según el RGPD, aunque lo habitual en una indisponibilidad temporal sea concluir que no requiere notificación.

Evidencias que hay que guardar ya

Lo que no se documenta esta semana será difícil de reconstruir dentro de un mes, cuando lo pida un auditor o un supervisor:

• La exportación del estado de servicio en UTC, los identificadores EX1550543 y MO1550821 y, cuando salga, el informe posterior al incidente.
• Una cronología interna con el momento en que la organización tuvo conocimiento, el de la clasificación y cada decisión con su responsable.
• La revisión del acuerdo de nivel de servicio de Microsoft: los créditos de servicio se solicitan por el centro de administración y dentro de plazo.
• El registro del incidente en el sistema de gestión de seguridad de la información (SGSI), según los controles 5.24 a 5.30 de ISO 27001:2022, y la revisión del análisis de impacto y de los tiempos de recuperación de los procesos que dependen de Microsoft 365.

¿Cómo se trabaja sin Microsoft 365?

Tres comprobaciones indican si el plan de respuesta a incidentes resiste una caída del propio proveedor:

• Un canal de coordinación del equipo de seguridad que no dependa de Teams ni de cuentas de Entra ID, y una cuenta de emergencia excluida del acceso condicional y protegida con llave física FIDO2 para poder administrar el inquilino.
• La telemetría de seguridad exportada a un área de trabajo de Log Analytics o un SIEM de la organización mediante la API de transmisión de Defender (Streaming API) o un conector, de modo que la investigación no dependa del portal de Defender.
• Una lista de los procesos que dependen del correo y el calendario, con su alternativa durante un día entero.

Para las entidades sujetas a DORA, probar el plan de continuidad de negocio TIC y revisar lo ocurrido tras una perturbación grave es una obligación expresa.

Lo que queda por saber

Falta la causa raíz confirmada, la hora de recuperación por región y la respuesta que más importa a un equipo de seguridad: si Defender, Intune y Purview dejaron de procesar o solo de mostrarse en los portales. Si el informe posterior al incidente no lo aclara, el cliente debería plantear esa pregunta a Microsoft por escrito. De esa respuesta dependerá qué comprobaciones de seguridad de Microsoft 365 de este artículo hay que reforzar.

Las consultas KQL y las comprobaciones son orientativas y deben adaptarse a la configuración, las licencias y la retención de cada inquilino. Este análisis se basa en las comunicaciones públicas de Microsoft, su documentación técnica y la cobertura de los medios citados, con información disponible a 13 de noviembre de 2026, cuando la incidencia seguía abierta y sin causa raíz confirmada. Las referencias a DORA, NIS2, ENS y RGPD son divulgativas y no sustituyen el análisis jurídico de cada entidad.