La VM olvidada que abrió la puerta a Storm-2603: lecciones críticas tras la brecha de SmarterTools

La semana pasada, SmarterTools confirmó lo que ya habían empezado a sospechar varios equipos de respuesta: un servidor de correo que no estaba actualizado sirvió de puerta de entrada para el grupo de ransomware conocido como Warlock o Storm‑2603. El incidente, que la compañía sitúa el 29 de enero de 2026, explotó una instancia de SmarterMail que no había recibido los parches más recientes y permitió a los atacantes moverse dentro de la red.

Según los comunicados oficiales de la propia SmarterTools, el vector inicial no fue una sofisticada cadena de exploits desconocida, sino la existencia de una máquina virtual olvidada por procesos internos de actualización. Ese único equipo, configurado por un empleado, quedó fuera del ciclo de parches y proporcionó el acceso que los operadores del grupo necesitaban para escalar privilegios y desplegar herramientas maliciosas en el entorno. Puedes leer la explicación de la compañía en su portal comunitario aquí.

El alcance técnico del ataque describe una táctica ya vista en campañas recientes: los intrusos no actúan de inmediato para cifrar y reclamar rescate, sino que permanecen en silencio lo suficiente como para asegurar persistencia y preparar el escenario. SmarterTools indica que los atacantes esperaron varios días antes de tomar control del servidor de Active Directory, crear cuentas y desplegar cargas útiles adicionales como Velociraptor y un componente de cifrado. Ese periodo de latencia explica por qué algunos clientes detectaron actividad maliciosa después de aplicar parches: la intrusión inicial había ocurrido antes de la actualización y solo se activaron las cargas en una fase posterior.

Las consecuencias no fueron triviales. La empresa confirmó que una docena de servidores Windows en la red de oficinas y un centro de datos secundario usado para pruebas de control de calidad resultaron afectados. Además, la operación impactó a clientes alojados que usan SmarterTrack; SmarterTools remarcó que el problema no fue un fallo en SmarterTrack como producto, sino que aquellas plataformas alojadas fueron más accesibles desde la red comprometida tras el acceso inicial. SmarterTools detalla su evaluación y recomendaciones en otra nota del portal comunitario disponible aquí.

Desde la perspectiva técnica, hay dos vulnerabilidades en SmarterMail que han recibido atención por su explotación activa. Una permite eludir la autenticación y restablecer la contraseña del administrador enviando una petición HTTP manipulada; la otra ataca la API ConnectToHub para conseguir ejecución remota sin autenticación. Ambos fallos ofrecen caminos distintos pero con el mismo objetivo: obtener control del sistema. SmarterTools corrigió estas fallas en una versión posterior y recomienda actualizar a la más reciente, que puedes consultar en sus notas de versión aquí.

Los informes de inteligencia que han seguido al incidente aportan detalles relevantes sobre la cadena de explotación. ReliaQuest, por ejemplo, describió cómo la campaña vinculada a Storm‑2603 abusó de la vulnerabilidad de restablecimiento de contraseñas para instalar un instalador MSI malicioso alojado en Supabase, que a su vez desplegó Velociraptor para mantener acceso y preparar el cifrado. Puedes leer su análisis técnico en su blog aquí. Además, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) ya ha señalado la explotación activa de una de estas vulnerabilidades, lo que subraya la urgencia de mitigación a nivel global; su catálogo de vulnerabilidades explotadas ofrece contexto sobre cómo estas fallas se priorizan por riesgo y explotación real (KEV catalog — CISA).

Más allá del nombre del malware y de las CVE, hay una lección operativa muy clara: los atacantes están afinando su metodología para "mezclarse" con el tráfico administrativo legítimo. En lugar de depender únicamente de exploits ruidosos que disparan alarmas, la campaña encadena un fallo de autenticación con funciones legítimas del software, como el montaje de volúmenes, para ejecutar código y permanecer desapercibida. Esta táctica reduce la eficacia de muchas detecciones que buscan patrones clásicos de RCE y obliga a defensas más holísticas que incluyan telemetría de actividad administrativa y detección de herramientas de persistencia.

Si gestionas SmarterMail, la primera medida imperativa es actualizar cuanto antes a la versión recomendada por el proveedor. Actualizar no es un gesto simbólico: cierra vectores que están siendo weaponizados activamente. Al mismo tiempo, es imprescindible segregar los servidores de correo de otros activos críticos, limitar la exposición a Internet y aplicar controles de red que impidan el movimiento lateral en caso de compromiso. La monitorización de Active Directory y la búsqueda de artefactos de persistencia —por ejemplo servicios, tareas programadas o binarios inusuales como Velociraptor— son pasos que deben formar parte de una respuesta rápida.

Finalmente, no conviene dormir en los laureles por comunicados tranquilizadores: aunque SmarterTools ha indicado que su web, la pasarela de compras, el portal de cuentas y ciertos servicios no se vieron comprometidos, la realidad del incidente muestra cómo una única VM olvidada puede afectar a sistemas conectados y a clientes alojados. La mejor defensa sigue siendo una combinación de higiene (parches, segmentación, copias de seguridad offline), monitorización franca de señales de intrusión y planes de respuesta que permitan contener y erradicar actores que ya hayan logrado acceso. Para quienes quieran profundizar en cómo se están explotando estas vulnerabilidades y qué buscar en entornos comprometidos, los análisis de ReliaQuest y los avisos de proveedores y agencias como CISA son lecturas recomendadas.

Si necesitas, puedo ayudarte a traducir estas recomendaciones a una lista de verificación práctica para equipos técnicos o a elaborar una comunicación para clientes que explique los pasos que deben seguirse tras la actualización.