El ransomware ha subido en la pila: los hipervisores pasan del 3 % al 25 % de los casos
Hay un dato de Huntress que merece más atención de la que ha tenido. Entre los incidentes de cifrado malicioso que Huntress atendió durante 2025, la proporción de casos que llegaron al hipervisor pasó del 3 % en el primer semestre al 25 % en el segundo, y la mayor parte de ese salto lo aportó el grupo Akira. 1
Es multiplicar por ocho la proporción de casos que alcanzan la capa de virtualización, en un solo año. Es la telemetría de un único fabricante, no un censo del ecosistema, pero la tendencia es difícil de pasar por alto.
Economía pura
Cifrar una máquina virtual invitada te da los datos de una víctima y te obliga a superar la seguridad de una víctima. Comprometer el hipervisor abre la puerta a todos los invitados de esa máquina a la vez, y la seguridad propia de esos invitados —su EDR, su cortafuegos, sus parches cuidadosos— deja de importar, porque estás trabajando por debajo de todo eso.
El almacenamiento de las máquinas virtuales también es un objetivo concentrado. Ya sean los discos archivos qcow2, volúmenes LVM, un almacén VMFS o imágenes de Ceph, los datos de muchos clientes tienden a estar en un solo sitio bajo un único plano de administración. Desde el anfitrión, comprometer a cincuenta clientes no son cincuenta compromisos distintos.
Los planos de gestión del hipervisor se tratan demasiado a menudo como fontanería y no como la joya de la corona: redes de gestión planas, credenciales de administración compartidas, parcheo sin prisa y monitorización orientada a los invitados en lugar de al anfitrión.
Lo que lo agrava son las copias de seguridad
En abril escribimos sobre el compromiso del servicio de soporte que hay detrás. Un secuestro de sesión dio a un tercero acceso al sistema de soporte de Virtualizor, donde unos 1500 tickets antiguos, algunos de más de un año, contenían contraseñas de root en texto plano que los propios clientes habían pegado al pedir ayuda. Virtualizor dejó claro que la vulnerabilidad no estaba en su software y que los servidores comprometidos fueron aquellos cuyas contraseñas nunca se habían cambiado y cuyos paneles de administración y SSH no estaban tras un cortafuegos. 2 Aguas abajo aparecieron informes de ataques de ransomware que afectaron a varios proveedores de hosting, con pérdida de datos de clientes. 3
El patrón de estos incidentes se repite, y en realidad no va del cifrado.
El proveedor tenía copias de seguridad. Las copias eran accesibles desde el entorno comprometido, con credenciales que ese mismo compromiso entregó. Las copias dentro de la misma frontera de confianza caen con ella, y de ahí, y no del cifrado, sale la pérdida definitiva.
Una copia que comparte credenciales, confianza de red o frontera administrativa con producción puede fallar justo cuando la necesitas. Es una segunda copia dentro del mismo radio de explosión.
Cinco medidas que aguantan
Lo más importante son las copias fuera del proveedor, y son justo las que casi todo el mundo se salta. No otro volumen, ni otra región, ni otro producto del mismo fabricante, sino un proveedor completamente distinto, con credenciales que no existan en ningún sitio de tu entorno de producción.
Separa producción de la autoridad sobre las copias. La dirección de la transferencia importa menos que el modelo de permisos: producción no debe poder destruir el histórico. Lo más limpio es que el sistema de copias entre y tire de los datos, sin que producción tenga credencial alguna. Una cuenta que pueda escribir pero nunca borrar da la misma propiedad allí donde el modelo push es inevitable. Lo que no funciona es que las credenciales que viven en tu máquina de producción puedan además vaciar el repositorio de copias, porque el ransomware que entre ahí las hereda.
Inmutabilidad: object-lock o almacenamiento de solo anexado, para que un atacante con credenciales válidas siga sin poder borrar el histórico.
Simulacros de restauración, porque una copia sin probar es una hipótesis. Restaura algo real, con periodicidad, y cronométralo.
Cifrado antes de salir, para que un proveedor de copias comprometido sea un problema de disponibilidad y no de divulgación.
KVM, y un punto en contra de nuestro propio interés
Dos cosas conviene decirlas claras, porque son estructurales y no promesas.
Usamos virtualización KVM completa, no contenedores compartidos. El aislamiento entre clientes descansa en la virtualización asistida por hardware y en la frontera del hipervisor, no en espacios de nombres ni en el modelo de permisos de un panel. Eso no es inmunidad: un anfitrión comprometido lo está en cualquier plataforma. Pero la frontera de aislamiento entre tú y el cliente de al lado se impone en la capa de virtualización, no a través de un kernel invitado compartido. No hay kernel común que una escalada local de privilegios pueda cruzar.
También tienes consola virtual desde el área de cliente. Todos los VPS y VDS de nuestro catálogo actual cuentan con consola noVNC, así que durante una recuperación no dependes de que SSH funcione, de que la red esté cuerda ni de enviarle una credencial a nadie.
Y aquí va la parte que va contra nuestro interés comercial: no guardes tu única copia de seguridad con nosotros. Tenemos cuatro países, y un segundo VPS en otra de nuestras sedes, desde 5 €/mes, sirve como copia separada que sobrevive a un fallo regional o jurisdiccional. No vendemos un producto gestionado de copias, así que ese montaje lo construyes tú. Y tampoco ayuda si los que fallamos somos nosotros. Para eso necesitas una copia en un proveedor cuyas credenciales no hayamos visto nunca.
Cualquier empresa de hosting que te diga otra cosa te está vendiendo un punto único de fallo con una pegatina de «redundancia».
La pregunta que hay que hacerle a tu proveedor
Si esta noche comprometen el plano de gestión de tu hipervisor, ¿qué sobrevive de lo mío y cuánto tardo en recuperarlo?
Tienes derecho a preguntarlo. La respuesta, y lo rápido que llegue, te dirá casi todo lo que necesitas saber.