El reciente incidente de seguridad que afectó a SmarterTools, desarrollador del popular servidor de correo SmarterMail, ilustra de forma contundente cómo una vulnerabilidad crítica combinada con retrasos en la gestión de parches puede desembocar en un ataque de ransomware masivo, incluso contra la propia infraestructura del fabricante.
Ataque de ransomware a SmarterTools: entrada por un SmarterMail desactualizado
El 29 de enero de 2026, la agrupación china Warlock (también conocida como Gold Salem y Storm-2603) comprometió la red interna de SmarterTools y desplegó ransomware en alrededor de 30 servidores de correo. El impacto alcanzó tanto la red de oficinas como servidores en el centro de datos utilizados para pruebas de calidad (QA).
Según la propia compañía, el punto de entrada fue una máquina virtual con una versión obsoleta de SmarterMail. Un empleado la puso en producción sin aplicar las últimas actualizaciones de seguridad. Esta brecha fue suficiente para que los atacantes explotaran una vulnerabilidad crítica y obtuvieran control sobre varios servidores.
Aunque Warlock logró desplegar el malware, la solución de protección de endpoints SentinelOne detectó y bloqueó los intentos de cifrado, limitando el daño. Hubo interrupciones temporales, incluido el portal de soporte técnico, pero la segmentación de red frenó la propagación. Los sistemas más afectados fueron servidores Windows (en torno a 12 máquinas), mientras que la infraestructura Linux permaneció prácticamente intacta.
Vulnerabilidad SmarterMail CVE-2026-24423: ejecución remota de código sin autenticación
El vector principal del ataque fue la vulnerabilidad CVE-2026-24423, valorada con 9,3 en la escala CVSS y listada por CISA en su catálogo de vulnerabilidades explotadas activamente (KEV), con indicación expresa de uso en campañas de ransomware. El parche se publicó el 15 de enero de 2026 en la versión SmarterMail Build 9511, dos semanas antes del ataque, y el análisis técnico apareció el 22 de enero a cargo de WatchTowr Labs, sólo una semana antes de la intrusión.
API insegura: endpoint /api/v1/settings/sysadmin/connect-to-hub
El problema residía en la implementación insegura del endpoint /api/v1/settings/sysadmin/connect-to-hub. Este servicio de la API:
– no requería autenticación;
– aceptaba datos JSON mediante solicitudes POST;
– confiaba ciegamente en el parámetro hubAddress, que apuntaba a un servidor remoto.
El atacante podía enviar una petición indicando en hubAddress un servidor bajo su control. El SmarterMail vulnerable se conectaba a ese host para obtener la configuración y el adversario respondía con un JSON que incluía el parámetro CommandMount con un comando arbitrario del sistema operativo. El servidor de correo ejecutaba entonces ese comando, permitiendo ejecución remota de código (RCE) sin autenticación.
Este tipo de vulnerabilidad es especialmente grave porque se puede automatizar con facilidad: los delincuentes pueden escanear internet en busca de instancias de SmarterMail vulnerables y comprometer en masa infraestructuras de correo corporativo, que suelen ser activos críticos y altamente expuestos.
Ventana de explotación tras la publicación del parche
La cronología del caso es significativa desde la perspectiva de la gestión de vulnerabilidades: parche el 15 de enero, detalles públicos el 22 de enero y ataque el 29 de enero. Este patrón refleja una tendencia generalizada: en cuanto se divulgan detalles técnicos de una vulnerabilidad crítica, los grupos de ransomware aceleran su explotación antes de que las organizaciones puedan actualizar todos sus sistemas.
Grupo Warlock: foco en entornos Windows y aplicaciones empresariales
La banda Warlock se ha caracterizado por explotar fallos en soluciones empresariales ampliamente desplegadas, como Microsoft SharePoint o plataformas de backup Veeam. La incorporación de SmarterMail a su catálogo de objetivos encaja con su estrategia de atacar principalmente entornos Windows, lo que explica que los servidores Linux de SmarterTools resultaran mínimamente afectados.
Tras la intrusión inicial, Warlock suele mantener una presencia silenciosa durante 6–7 días antes de activar el cifrado. En ese periodo realizan reconocimiento, intentan tomar el control de los controladores de dominio de Active Directory, crean cuentas nuevas y distribuyen herramientas por los equipos Windows. Esta táctica de “compromiso primero, cifrado después” explica por qué algunos clientes de SmarterMail sufrieron ransomware incluso después de aplicar las actualizaciones: la explotación de la vulnerabilidad se había producido antes del parche y la activación del malware se retrasó deliberadamente.
Otras vulnerabilidades críticas en SmarterMail: CVE-2026-23760 y CVE-2026-25067
En las semanas previas al ataque se identificaron otras dos debilidades relevantes en SmarterMail:
– CVE-2026-23760 (CVSS 9,3): otra vulnerabilidad de ejecución remota de código, también reportada como explotada activamente;
– CVE-2026-25067 (CVSS 6,9): fallo que permite ataques de NTLM relay a través del endpoint background-of-the-day preview.
Ambas fueron corregidas en las versiones Build 9511 y 9518. La concentración de varios fallos críticos en un mismo producto subraya la necesidad de un ciclo de parcheo riguroso que incluya no sólo los servidores de producción, sino también máquinas de laboratorio, entornos de QA y VM temporales, que a menudo quedan fuera de los procesos formales de gestión de parches.
Respuesta de SmarterTools y medidas recomendadas para proteger SmarterMail
Tras el incidente, SmarterTools anunció una revisión profunda de su arquitectura. En aquellos segmentos donde fue posible, se redujo la dependencia de Windows, se decidió abandonar Active Directory y se procedió al reseteo y regeneración de todas las contraseñas. La empresa también comunicó la ampliación de sus auditorías de seguridad y una mayor colaboración con investigadores externos.
A los clientes de SmarterMail se les recomienda actualizar de inmediato a la versión Build 9526 (22 de enero de 2026) y revisar los registros en busca de accesos al endpoint /api/v1/settings/sysadmin/connect-to-hub. En las versiones corregidas, este endpoint responde con un código HTTP 400 y un mensaje de error, lo que permite distinguir rápidamente las instalaciones seguras de las vulnerables.
Más allá del caso concreto, el incidente deja varias lecciones prácticas para cualquier organización que opere servidores de correo u otras aplicaciones expuestas a internet: mantener inventarios completos de activos, aplicar parches sin demoras en todos los sistemas (incluidas VM de prueba), segmentar la red, desplegar soluciones EDR, limitar los privilegios de las cuentas de servicio y monitorizar de forma continua los logs y APIs en busca de actividad anómala. La combinación de una gestión de vulnerabilidades madura y una arquitectura defensiva basada en el principio de mínimo privilegio sigue siendo la mejor estrategia para reducir el riesgo de convertirse en la próxima víctima de un ataque de ransomware.
