Microsoft Exchange Hafnium: 4 zero-days y ~250,000 servidores comprometidos globalmente
Ayer, 2 de marzo, Microsoft publicó parches de emergencia para cuatro vulnerabilidades de día cero en Exchange Server, atribuidas a un grupo de actores patrocinado por el estado chino al que llaman Hafnium. Las vulnerabilidades, agrupadas bajo el nombre ProxyLogon (CVE-2021-26855 es la cabeza de la cadena, acompañada por CVE-2021-26857, CVE-2021-26858 y CVE-2021-27065), permiten a un atacante remoto, sin autenticación previa, ejecutar código arbitrario en un servidor Exchange expuesto a Internet.
Las estimaciones iniciales hablan de aproximadamente 250 mil servidores comprometidos globalmente, con miles de organizaciones afectadas en cuestión de días. Es uno de los incidentes más graves de seguridad de la última década, comparable en alcance a SolarWinds. En ALCA llevamos dos días hablando con clientes que tienen Exchange on-premises sobre qué hacer en este momento. Queremos compartir lo más relevante.
Qué hace exactamente la cadena ProxyLogon
Las cuatro vulnerabilidades se encadenan para permitir un escenario completo de compromiso. Primero, CVE-2021-26855 es una vulnerabilidad de Server-Side Request Forgery (SSRF) que permite al atacante enviar peticiones HTTP arbitrarias autenticándose como el servidor Exchange. Eso, por sí solo, es serio: el atacante puede leer correos sin necesidad de credenciales de usuario.
Segundo, CVE-2021-26857 es una falla de deserialización en el servicio Unified Messaging que permite ejecución de código como SYSTEM, el usuario más privilegiado de Windows. Tercero y cuarto, CVE-2021-26858 y CVE-2021-27065, permiten escribir archivos arbitrarios en el sistema, lo cual los atacantes usan para colocar web shells (típicamente archivos ASPX) en directorios accesibles vía web.
Una vez plantado el web shell, el atacante tiene acceso persistente al servidor incluso si Microsoft parcha la vulnerabilidad después. Por eso parchar no es suficiente: hay que asumir compromiso y hacer respuesta a incidentes en cualquier servidor que estuvo expuesto.
Quién es Hafnium y por qué importa la atribución
Microsoft atribuye los ataques a Hafnium, un grupo que opera desde China con alta probabilidad asociado al estado. Los objetivos típicos del grupo incluyen pensadores políticos, defensores de derechos humanos, contratistas de defensa, instituciones académicas y grupos de investigación en enfermedades infecciosas. Pero una vez que las vulnerabilidades se hicieron públicas, decenas de otros grupos (incluyendo cibercriminales sin afiliación estatal) empezaron a explotarlas, ampliando masivamente el alcance del daño.
La atribución importa porque Hafnium opera con paciencia y profesionalismo: pueden haber comprometido servidores meses antes de la divulgación pública y simplemente esperaron, manteniendo acceso. Eso significa que muchas organizaciones no van a saber que están comprometidas hasta que apliquen análisis forense detallado.
Qué hacer si tu empresa tiene Exchange on-premises
Si tu organización opera Exchange Server (2013, 2016 o 2019) en sus propias instalaciones o en una nube privada, las acciones de las próximas 48 horas son críticas.
Acción uno: parchar inmediatamente. Microsoft liberó actualizaciones de seguridad fuera de ciclo. No esperes a la próxima ventana de mantenimiento. Aplica los parches hoy mismo, incluso si afecta brevemente la disponibilidad del servicio. La alternativa, no parchar, es mucho peor.
Acción dos: ejecutar el script de detección de Microsoft. Microsoft publicó scripts en PowerShell que buscan indicadores de compromiso, principalmente web shells conocidos asociados a Hafnium. Ejecuta este script en cada servidor Exchange. Si encuentra algo, asume compromiso completo y activa tu plan de respuesta a incidentes.
Acción tres: revisar logs de IIS. Las explotaciones dejan rastro en los logs del servidor web. Patrones específicos de URLs (que están publicados en los advisories de varios proveedores de seguridad) son indicadores fuertes. Si no tienes capacidad interna para hacer este análisis, vale la pena contratar a un especialista.
Acción cuatro: si encuentras compromiso, reconstruir el servidor. Limpiar un servidor comprometido es difícil y arriesgado. Los atacantes pueden haber instalado puertas traseras adicionales que no son evidentes. La opción más segura es reconstruir el servidor desde cero y restaurar buzones desde respaldos previos al compromiso.
Por qué este incidente acelera la conversación de Exchange Online
Para muchas empresas mexicanas que aún operan Exchange on-premises por razones de costos, soberanía de datos o inercia, este incidente cambia la conversación. Migrar a Exchange Online (parte de Microsoft 365) tiene varias ventajas concretas que se vuelven más visibles después de un episodio así.
Primero, la responsabilidad de parchar la infraestructura pasa a Microsoft. Para vulnerabilidades como ProxyLogon, la mitigación habría sido transparente para el cliente. Segundo, las capacidades de detección y respuesta de Microsoft a nivel global son superiores a lo que la mayoría de empresas medianas pueden mantener internamente. Tercero, los costos de operar Exchange on-premises (licencias, hardware, capacitación, parches, monitoreo) ya no son notoriamente menores que la suscripción mensual a Microsoft 365.
Eso no significa que toda empresa deba migrar mañana. Hay sectores con regulación específica que limita dónde pueden residir los datos, y hay arquitecturas integradas que toman tiempo migrar. Pero la conversación operativa cambia: el costo de mantener Exchange on-premises ya incluye el riesgo concreto de eventos como Hafnium, no solo la complejidad técnica.
Lecciones más amplias para CISOs mexicanos
Tres lecturas que van más allá del incidente específico.
La primera es que la cadena de suministro de software es un vector de ataque que requiere atención dedicada. SolarWinds en diciembre, Hafnium ahora en marzo: en menos de cuatro meses dos eventos de magnitud histórica han mostrado que confiar en un proveedor no exime de la responsabilidad de tener visibilidad y controles propios.
La segunda es que la exposición de servicios a Internet debe minimizarse hasta donde sea técnicamente posible. Exchange históricamente requería exponer ciertas interfaces; pero hay arquitecturas, como Exchange Online o el uso de gateways de aplicaciones con autenticación previa, que reducen la superficie de ataque significativamente. Cada servicio expuesto es una hipoteca futura.
La tercera es que los planes de respuesta a incidentes solo funcionan si se han ensayado. Una empresa que esta semana tuvo que activar su plan por primera vez está en posición mucho peor que una que ya había hecho simulacros. Ensayar incidentes, una vez al trimestre, con el equipo real, debería ser estándar.
ProxyLogon va a estar en agenda durante semanas. Las empresas que reaccionan rápido y bien van a salir relativamente bien. Las que minimizan el evento van a descubrir tarde el costo real de no tomarse esto en serio.
¿Tu Exchange on-prem está protegido? Hagamos assessment. En ALCA realizamos assessments de exposición y respuesta para empresas con infraestructura Microsoft on-premises o híbrida. Agenda una sesión urgente sin costo.
