Recientemente, varios clientes reportaron que sus aplicaciones basadas en Exchange Web Services (EWS) dejaron de responder en Exchange Online. La causa raíz es la desactivación de la API EWS, que Microsoft retiró como parte de la evolución de sus servicios de mensajería. Esta interrupción afecta a soluciones de sincronización, archivado y automatización que aún dependen de EWS. Microsoft ha publicado una guía para que los administradores vuelvan a habilitar la API y restablezcan la operatividad de esas aplicaciones.

Qué sabemos hasta ahora

Según la documentación oficial, la API EWS fue marcada como obsoleta y, a partir de una fecha específica, quedó deshabilitada por defecto en los inquilinos de Exchange Online. La medida buscaba incentivar la migración a Microsoft Graph, que ofrece mayor seguridad y funcionalidad. Sin embargo, muchas organizaciones mantienen aplicaciones legadas que no han sido migradas y, al perder acceso a EWS, experimentaron fallos en procesos críticos.

Microsoft ha confirmado que la reactivación de EWS es una opción soportada, aunque temporal, mientras se completan los proyectos de migración. La guía indica que los administradores pueden volver a habilitar la API a nivel de organización mediante PowerShell o el centro de administración.

Análisis técnico

La reactivación se realiza mediante el cmdlet de PowerShell Set-OrganizationConfig -EwsEnabled $true, que vuelve a exponer los endpoints de EWS en el tenant. Una vez habilitada, las aplicaciones pueden volver a autenticarse usando los mismos métodos de OAuth o credenciales básicas que utilizaban previamente. Es importante validar que los permisos de aplicación (delegados o de aplicación) siguen alineados con las políticas de seguridad actuales.

Desde el punto de vista de la superficie de ataque, volver a habilitar EWS reintroduce vectores que Microsoft había intentado mitigar, como la exposición de endpoints SOAP y la posibilidad de abuso de credenciales comprometidas. Por ello, se recomienda limitar el acceso a direcciones IP de confianza y monitorizar los logs de EWS para detectar patrones anómalos.

"Reactivar EWS es una solución de contingencia mientras se completa la migración a Microsoft Graph", indica el equipo de Exchange Online de Microsoft.

Impacto y alcance

La vulnerabilidad que afecta a Exchange Online y la necesidad de reactivar EWS (Exchange Web Services) tiene repercusión en cualquier organización que dependa de la integración de correo electrónico con aplicaciones de terceros, como sistemas de gestión documental, plataformas de automatización de flujos de trabajo y herramientas de colaboración. Los sectores más expuestos son los que manejan grandes volúmenes de correo y dependen de la interoperabilidad con servicios externos, como finanzas, salud, educación y gobiernos locales.

Los riesgos se concentran en entornos donde EWS está deshabilitado por defecto y donde los administradores no han revisado la configuración tras los últimos cambios de Microsoft. Hasta el momento no se ha reportado un exploit público que aproveche directamente la desactivación de EWS, pero la exposición a ataques de phishing o a la manipulación de credenciales sigue siendo una amenaza latente para los sistemas que dependen de este punto de integración.

¿Cómo afecta esto a LATAM?

En América Latina, muchas empresas y entidades públicas utilizan Microsoft 365 como plataforma principal de correo y colaboración. Países como México, Colombia y Argentina cuentan con una amplia base de clientes que integran sus sistemas internos con EWS para automatizar procesos críticos, como la generación de facturas electrónicas o la sincronización de agendas corporativas.

La falta de una guía clara para reactivar EWS puede dejar a estas organizaciones vulnerables a interrupciones operativas o a la imposibilidad de mantener flujos de trabajo automatizados. Además, la dependencia de proveedores locales de servicios gestionados que configuran entornos de Exchange Online sin revisar la activación de EWS aumenta la probabilidad de que la situación pase desapercibida hasta que se produzca un incidente.

Qué deben hacer los equipos de seguridad

  • Revisar la configuración actual de Exchange Online y confirmar si EWS está deshabilitado en los buzones críticos.
  • Seguir la guía oficial de Microsoft para reactivar EWS mediante PowerShell o el Centro de administración de Exchange, asegurándose de documentar cada cambio.
  • Implementar controles de acceso basados en el principio de menor privilegio para las cuentas que necesiten interactuar con EWS.
  • Monitorear los logs de actividad de Exchange en busca de intentos de acceso no autorizados o patrones de comportamiento anómalos relacionados con EWS.
  • Actualizar las políticas de seguridad de correo electrónico para incluir la revisión periódica de la configuración de EWS como parte de los procesos de auditoría.
  • Comunicar a los equipos de desarrollo y a los proveedores de aplicaciones la necesidad de validar la compatibilidad con la configuración de EWS antes de desplegar nuevas integraciones.

Reflexión

¿Estamos preparados para gestionar la complejidad que implica mantener servicios críticos como EWS activos y seguros en un entorno cloud que evoluciona constantemente? La respuesta no es sencilla: mientras más dependamos de integraciones automatizadas, mayor será la necesidad de equilibrar la agilidad operativa con una vigilancia continua. La pregunta que queda es si las organizaciones están dispuestas a invertir el tiempo y los recursos necesarios para no quedar atrapadas en una brecha de configuración que, aunque invisible, puede convertirse en la puerta de entrada a incidentes mayores.