En 2025, los eventos de cifrado malicioso a nivel hipervisor pasaron de representar el 3% al 25% del total de incidentes de ransomware registrados -un crecimiento de 8 veces en un solo año, según datos de Huntress. Si tu servidor de respaldos o tu repositorio inmutable corren como máquina virtual dentro del mismo hipervisor que protegen, ese dato te toca directamente: un atacante que llegue a esa capa ya no necesita comprometerlos uno por uno, los apaga a todos de un solo golpe.
¿Qué tan real es el ransomware a nivel hipervisor?
No es una amenaza emergente ni un escenario de conferencia. Los números de 2025 lo confirman con cifras concretas:
- De 3% a 25% del total de eventos de cifrado malicioso fueron a nivel hipervisor durante 2025 -crecimiento de 8x en doce meses (Huntress).
- 7,419 ataques de ransomware se registraron en el mundo en 2025, +32% respecto a 2024 (Comparitech).
- La CVE-2025-22225, una vulnerabilidad de escritura arbitraria en VMware ESXi que Broadcom corrigió en marzo de 2025, sigue explotándose activamente en campañas de ransomware -CISA confirmó su uso en ataques reales.
- En marzo de 2026, Rapid7 documentó más de 900 incidentes de ransomware reportados públicamente, incluyendo payloads dirigidos específicamente a infraestructura ESXi en el mismo evento que a servidores de archivos Windows.
Un dato que parece buena noticia, pero no lo es del todo: la exposición directa de servidores ESXi a internet cayó 90% (de 85,000 a cerca de 8,900, según Forescout). El problema es que ese número mide solo acceso directo desde internet. El vector real hoy no es "alguien encuentra tu hipervisor expuesto en un escaneo" -es movimiento lateral después de comprometer cualquier otro punto de la red. Un hipervisor sin exposición a internet no está a salvo si un atacante ya está dentro.
¿Por qué un ataque al hipervisor es distinto a uno a una máquina virtual?
Cuando el ransomware cifra una VM, pierdes esa VM. Cuando compromete el hipervisor, pierdes todo lo que corre sobre él al mismo tiempo -y ahí es donde el diseño típico de muchas operaciones se vuelve autodestructivo. El patrón que hemos visto de cerca: un ataque con una variante de ESXiArgs, propagado por movimiento lateral, que dejó inhabilitados todos los hosts ESXi de una organización en un solo evento -servidor de respaldos y repositorios incluidos, porque los tres vivían en la misma capa comprometida.
Esto no es un caso aislado. Es la consecuencia lógica de una decisión de arquitectura muy común: virtualizar el servidor de Veeam y el repositorio inmutable dentro del mismo clúster que protegen, porque es lo más simple de desplegar. Simple hasta el día que el hipervisor mismo es el objetivo, no un intermediario más.
¿Qué exposición tiene un entorno típico, aunque nunca haya estado en internet?
Vale la pena revisar tres preguntas concretas sobre tu propio entorno, sin necesidad de una auditoría formal:
| Pregunta | Por qué importa |
|---|---|
| ¿Dónde corre tu servidor de Veeam? | Si es una VM en el mismo clúster que protege, comparte dominio de falla con lo que respalda. |
| ¿Dónde vive tu repositorio inmutable? | La inmutabilidad protege desde dentro del sistema de archivos, no desde fuera. Quien controla el hipervisor puede borrar la VM completa, sin tocar el mecanismo de bloqueo. |
| ¿Cuántos hosts de virtualización tienes? | Con menos de 3, ni siquiera hay margen de quorum -y menos aún de aislamiento real para continuidad. |
Si respondiste "sí" a las primeras dos, tu continuidad operativa depende de que el atacante nunca llegue a un solo punto -exactamente el escenario que el crecimiento de 8x en ataques a hipervisor vuelve cada vez menos improbable.
¿Qué cambia en la práctica?
La corrección no es exótica ni cara en comparación con el riesgo que resuelve:
- El servidor de respaldos corre fuera del hipervisor que protege -en hardware dedicado, aunque sea modesto.
- El repositorio inmutable va en bare-metal, sin capa de virtualización de por medio.
- Si estás evaluando salir de VMware, es el momento correcto para corregir esta decisión de arquitectura desde cero, en vez de migrar el mismo problema a la plataforma nueva -sobre todo si tus hosts actuales ya están al límite de capacidad.
No hace falta un proyecto grande para empezar: un equipo dedicado adicional, incluso modesto, ya rompe la dependencia de una sola capa comprometida.
¿Cuánto cuesta corregirlo comparado con el riesgo?
La comparación no es sutil. Un equipo dedicado modesto para hostear el respaldo y el repositorio inmutable fuera del clúster de producción cuesta una fracción de lo que representa perder simultáneamente producción, respaldo y repositorio en un solo evento -que es exactamente el escenario que describe el crecimiento de 8x en ataques a nivel hipervisor durante 2025. No se trata de duplicar infraestructura completa: se trata de sacar dos piezas específicas -el motor de respaldos y el repositorio inmutable- de la capa que comparten hoy con todo lo demás.
Tampoco es una decisión que dependa de tener presupuesto de proyecto grande. Es más parecida a comprar un extintor que a remodelar el edificio: una pieza de hardware acotada, con un objetivo único y medible -que el mecanismo de inmutabilidad en el que ya invertiste realmente cumpla lo que promete.
Preguntas frecuentes
help ¿Qué tan probable es un ataque de ransomware a nivel hipervisor, no solo a una VM?
Mucho más probable que hace un año: los eventos de cifrado malicioso a nivel hipervisor pasaron de 3% a 25% del total durante 2025, un crecimiento de 8 veces, según datos de Huntress. Ya no es un vector marginal.
help ¿Por qué la exposición de ESXi a internet cayó 90% si el riesgo está creciendo?
Porque esa cifra mide solo acceso directo desde internet, y no es el vector principal hoy. El riesgo real viene de movimiento lateral después de comprometer cualquier otro punto de la red -un hipervisor sin exposición pública no está protegido si el atacante ya está dentro.
help ¿Sirve de algo tener respaldos si Veeam y el repositorio corren en el mismo clúster que protegen?
Sirve contra fallas de hardware o errores humanos, pero no contra un compromiso del hipervisor mismo: quien controla esa capa puede borrar la VM del repositorio sin tocar el mecanismo de inmutabilidad que corre dentro de ella. El respaldo y el entorno que protege terminan compartiendo el mismo punto único de falla.
help ¿Qué tan grande tiene que ser el proyecto para corregir esto?
No hace falta un proyecto grande. Un equipo adicional dedicado, incluso modesto, para hostear el servidor de respaldos y el repositorio inmutable fuera del hipervisor de producción ya rompe la dependencia de una sola capa comprometida -es una corrección de arquitectura puntual, no una migración completa.
Rubén Espinoza es fundador y Director Técnico de IT Experts de México. Trabaja en la industria de TI desde 1998: diseña y opera soluciones de infraestructura, ciberseguridad, continuidad, automatización y tecnología OT para entornos empresariales e industriales. Escribe desde proyectos reales y sistemas en producción.
Ver perfil y todos sus artículos →