Los servidores de virtualización VMware ESXi llevan siendo objetivo prioritario del ransomware desde 2022, cuando el grupo ESXiArgs lanzó la primera campaña masiva que aprovechó una vulnerabilidad de OpenSLP para comprometer miles de hosts en pocas horas. Cuatro años después, la situación no ha mejorado sustancialmente: una nueva oleada de ataques documentada en las últimas semanas vuelve a centrarse en infraestructura ESXi, esta vez con variantes que combinan técnicas de movimiento lateral mejoradas con cifrado que afecta directamente a los datastores de las máquinas virtuales.
El patrón es siempre el mismo: un servidor ESXi expuesto a internet, con versiones sin parchear o con configuraciones permisivas, termina siendo el punto de entrada que les da acceso a toda la infraestructura virtualizada de la organización. Un solo servidor ESXi comprometido puede cifrar docenas de máquinas virtuales en minutos.
Por qué ESXi es un objetivo de primera categoría
La lógica del atacante es sencilla. En lugar de comprometer máquinas individuales una a una, un servidor ESXi es un concentrador: cifrar el hipervisor o sus datastores deja fuera de servicio todo lo que corre encima simultáneamente. Para el atacante, la relación esfuerzo-impacto es extraordinariamente favorable.
A eso se añade que muchas organizaciones que dependen de VMware para su infraestructura crítica tienen ciclos de actualización más lentos que el software de usuario final. Los entornos de producción no se parchean con la misma agilidad que un portátil corporativo. Y desde que Broadcom adquirió VMware y cambió radicalmente el modelo de licencias, una parte del ecosistema está en transición: organizaciones evaluando alternativas, contratos en renegociación, y en algunos casos, infraestructura que ha quedado en un limbo de soporte.
Las variantes más recientes de ransomware orientadas a ESXi están usando principalmente dos vectores. El primero es la explotación de vulnerabilidades conocidas en versiones sin parchear: CVE-2021-21985, CVE-2021-22005 y variantes del 2023 siguen apareciendo en análisis de incidentes recientes porque hay servidores que nunca se actualizaron. Esto encaja con el patrón que el informe de Cisco Talos documentó este año: el 32% de las vulnerabilidades más explotadas tiene más de diez años, y muchas siguen abiertas simplemente porque nadie se ha ocupado de cerrarlas. El segundo vector es el acceso mediante credenciales comprometidas, a menudo obtenidas previamente a través de un ataque de phishing a un administrador o mediante credenciales filtradas en brechas anteriores.
Qué está pasando con las variantes recientes
Los grupos detrás de las campañas actuales no son nuevos en este espacio. Akira, Black Basta y un puñado de variantes de ransomware-as-a-service llevan meses perfeccionando sus herramientas específicas para ESXi. Lo que ha cambiado en los últimos meses es la incorporación de técnicas de detección de snapshots: antes de cifrar, el malware identifica y elimina los snapshots de VMware para eliminar la posibilidad de recuperación sin pagar. Eso convierte lo que podría ser un incidente recuperable en una crisis real si no hay backups offline o fuera del entorno virtualizado.
Otra tendencia documentada es el uso de ESXi Shell y SSH como vías de persistencia. Una vez dentro, los atacantes activan estos servicios si estaban desactivados, lo que les permite mantener acceso aunque se detecte y bloquee el vector de entrada inicial. Es la misma lógica que llevó a LockBit 5.0 a incorporar capacidades de persistencia avanzadas en su última versión: entrar es la mitad del trabajo, quedarse es la otra mitad.
Qué revisar si gestionas infraestructura ESXi
El primer punto es la exposición a internet. Ningún servidor ESXi debería tener el puerto de gestión (443, 902, 903) accesible directamente desde internet sin una VPN o un bastión intermedio. Si está expuesto, ese es el primer problema a resolver antes que cualquier otro.
El segundo es la versión. VMware publica sus boletines de seguridad en el portal de Broadcom. Los servidores ESXi 6.x están fuera de soporte y no reciben parches de seguridad: cualquier vulnerabilidad nueva no va a tener solución oficial. ESXi 7.x y 8.x deben estar con los últimos parches aplicados.
El tercero es el modelo de backup. Los backups que viven en datastores del mismo ESXi comprometido no son backups útiles en un escenario de ransomware. La regla 3-2-1 (tres copias, dos soportes distintos, una offsite) sigue siendo el estándar mínimo, y en el contexto de ESXi implica tener al menos una copia fuera del entorno virtualizado.
El cuarto es la auditoría de cuentas y credenciales. Las cuentas de administrador de ESXi con contraseñas débiles o que llevan años sin rotarse son un riesgo asumido. La autenticación multifactor no está disponible de forma nativa en ESXi, pero se puede implementar a través del vSphere Client y soluciones de gestión de accesos privilegiados.
Por último, revisar que SSH y ESXi Shell estén desactivados en los hosts que no los necesiten activamente. Son servicios que conviene activar puntualmente para tareas de mantenimiento y desactivar inmediatamente después.
La infraestructura de virtualización lleva décadas siendo invisible para las discusiones de seguridad porque se asume que está "detrás de todo". Esa asunción es exactamente lo que los grupos de ransomware llevan años aprovechando.
0 Comentarios