Entre el viernes 28 de agosto a las 20:57 UTC y el domingo 30 a las 06:10, una red ajena anunció al resto de Internet, sin autorización, el bloque 162.55.80.0/24, un trozo del espacio de direcciones de Hetzner donde están alojados los servidores de actualización y de facturación de Softaculous. Mientras el anuncio se mantuvo, el tráfico de la mayor parte de Internet hacia esas direcciones acabó en un servidor controlado por el atacante.
Desde esa posición obtuvo un certificado TLS válido para 26 dominios de la compañía y sirvió una actualización troyanizada de Virtualizor, el panel con el que muchos proveedores de hosting gestionan sus servidores virtuales. Un proveedor ha contado que 5 de sus 34 hipervisores tenían instalada la puerta trasera con root.
El caso lo ha reconstruido el propio fabricante con datos públicos de enrutamiento, y BGPKIT lo ha verificado de forma independiente contra los mensajes BGP en bruto de los recolectores de rutas de RIPE y Route Views. En Hard2bit vamos a usarlo como caso de estudio, porque encadena tres mecanismos ajenos entre sí hasta llegar a un hipervisor comprometido.
¿Cómo se troyaniza una actualización sin tocar el servidor del fabricante?
La cadena tiene tres eslabones y en ninguno hubo una vulnerabilidad de software en el sentido clásico.
Primer eslabón: una ruta más específica con el origen legítimo
BGP, el protocolo con el que las redes de Internet se anuncian entre sí qué direcciones alcanzan, prefiere siempre la ruta más específica. Hetzner anuncia el bloque 162.55.0.0/16; el sistema autónomo AS62390, registrado como NexonHost, empezó a anunciar el subbloque 162.55.80.0/24 a través de su tránsito AS6204 (ZET.NET), y cada red que aceptó ese anuncio dejó de enviar el tráfico a Hetzner. Según el aviso de Virtualizor, en los picos alrededor del 72 % de los 368 observadores de RIPE RIS tenían la ruta falsa como mejor ruta, y los 368 llegaron a verla en algún momento.
El detalle que distingue este secuestro de uno burdo es que el anuncio conservó a Hetzner (AS24940) como origen aparente al final de la ruta, con AS62390 insertado inmediatamente antes.
Hubo dos oleadas, de unas 12 y 10 horas, con una pausa de 11 horas entre ambas; la ruta subía y caía tan a menudo que BGPKIT cuenta unas 10.600 retiradas en 33 horas. La primera oleada terminó cuando la propia Hetzner anunció el /24, unas 12 horas después del inicio y, como relata Softaculous, tras varios avisos suyos. Hetzner retiró ese anuncio hacia las 14:30 UTC del 29 y la segunda oleada empezó cinco horas más tarde, con el mismo alcance.
Segundo eslabón: un certificado válido emitido a quien controlaba la ruta
Con el tráfico desviado, el impostor pidió a Let's Encrypt un certificado para los dominios de Softaculous. La validación automática de control del dominio consiste en una petición HTTP a la dirección del dominio, y esa petición también viajó por la ruta secuestrada. El resultado fue un certificado válido para 26 nombres, entre ellos virtualizor.com, api.virtualizor.com y files.virtualizor.com; según el fabricante, las conexiones afectadas no mostraron ningún aviso de certificado.
Las autoridades de certificación validan desde varios puntos de la red para resistir secuestros de ruta, una práctica que el CA/Browser Forum ha ido haciendo obligatoria por fases desde marzo de 2025. Esa defensa asume que el secuestro es regional. Cuando la ruta falsa alcanza a tres de cada cuatro observadores del planeta, lo más probable es que todos los puntos de validación de la CA vean lo mismo. BGPKIT añade otro matiz: el certificado siguió siendo válido después de que la ruta se restaurara, hasta que se revocara (el aviso no da la hora), y BGPKIT sostiene que la segunda oleada volvió a usarlo.
Tercer eslabón: un cliente de actualización que confiaba en el canal
El último control estaba en el cliente de actualización de Virtualizor, que, como reconoce el fabricante, no verificaba criptográficamente los paquetes, de modo que una respuesta HTTPS válida de un servidor con el nombre correcto era suficiente. La actualización falsa se presentaba como la versión 3.2.9.8; los servidores afectados registraron una actualización correcta y permanecieron en la 3.2.9.7, un desajuste que BGPKIT, a partir de lo que han comunicado los operadores, considera por sí solo un indicador de compromiso.
Según el análisis del proveedor comprometido que recoge The Hacker News, el paquete modificaba tres ficheros legítimos de Virtualizor y una tarea programada de root ejecutaba después el código insertado: añadía una clave SSH del atacante a la cuenta root, instalaba Java si no estaba, descargaba un binario Java y lo dejaba como servicio de systemd para que sobreviviera a los reinicios, es decir, con persistencia, y creaba una cuenta adicional llamada proxyuser. Quien tiene root en el hipervisor tiene root en todas las máquinas virtuales que aloja.
Lo que se sabe del impacto
Virtualizor afirma que solo un pequeño número de instalaciones recibió el paquete malicioso, pero no puede dar una lista: las respuestas falsas las sirvió el atacante y jamás pasaron por sus registros. Por eso pide a todos los operadores que revisen cada servidor. Un proveedor de hosting (AlbaHost, en el foro LowEndTalk) ha comunicado que 5 de los 34 hipervisores que revisó contenían las modificaciones, sin evidencia por ahora de manipulación de las máquinas virtuales de sus clientes.
El área de clientes y la pasarela de pago también resolvían a las direcciones secuestradas; a 2 de septiembre no hay robo confirmado de cuentas ni de datos de pago, y el fabricante no ha identificado paquetes maliciosos de sus otros productos.
El 1 de septiembre Virtualizor publicó el parche 9 de la versión 3.2.9 con un analizador de seguridad y un script de comprobación. La firma criptográfica de paquetes figura en su lista de medidas como trabajo pendiente, según recoge también SecurityWeek, y en esa misma lista aparece la migración a otra infraestructura.
¿Por qué RPKI no lo detuvo?
La reacción habitual ante un secuestro BGP es preguntar por RPKI, el sistema que permite a los propietarios de direcciones publicar qué sistema autónomo está autorizado a originarlas. La respuesta sorprende, porque la ruta falsa era válida según RPKI. La autorización (ROA) de Hetzner cubre 162.55.0.0/16 con origen AS24940 y una longitud máxima de 24 bits; como el anuncio falso mantenía a AS24940 como origen y era exactamente un /24, cualquier router que validara origen lo aceptaba. Doug Madory, de Kentik, lo resumió en Bluesky, según recoge Risky Business: los secuestradores falsificaron el origen para que la ruta validara.
De ahí saca BGPKIT tres conclusiones. Si la ROA se hubiera firmado solo para el /16, sin longitud máxima 24, como recomienda la RFC 9319, el /24 habría sido inválido y las redes que validan lo habrían descartado. La pregunta que RPKI no puede responder es qué sistema autónomo puede aparecer inmediatamente antes del origen en la ruta, y ese hueco es el que cubre ASPA, una extensión en fase de borrador que ninguna red de la cadena tenía publicada. Y el control más viejo de todos habría confinado el anuncio a un solo salto, un filtro de prefijos de cliente en el proveedor de tránsito que lo aceptó.
Para quien contrata hosting, esto deja cuatro preguntas para el proveedor: si sus ROA evitan el campo de longitud máxima, si publica ASPA, si sus tránsitos filtran prefijos de cliente y si vigila anuncios más específicos dentro de sus bloques. En los cuestionarios de evaluación de proveedores que solemos ver, esas preguntas casi nunca aparecen; este caso da argumentos para incluirlas.
Qué hacer si operas Virtualizor
Virtualizor pide dar por afectado cualquier servidor hasta demostrar lo contrario, y la empresa que ha hablado públicamente sostiene que, ante un compromiso de root confirmado, la reconstrucción limpia es la única remediación fiable. Los pasos, a partir de lo que recomienda Virtualizor:
- Comprueba si existe la unidad de systemd java-jre-update.service y ejecuta el script oficial, que busca ese y el resto de indicadores conocidos. Si encuentra algo, preserva la evidencia y contacta con el soporte antes de limpiar.
- Compara la versión instalada con lo que dicen los registros de actualización.
- Regenera todas las credenciales de API del panel, restringe el acceso a la API a direcciones de confianza y elimina las que no reconozcas.
- Audita claves SSH desconocidas en root, cuentas nuevas, tareas programadas y conexiones salientes inesperadas, y restringe SSH a direcciones de confianza.
- Si iniciaste sesión en el área de clientes de Softaculous durante la ventana, cambia esa contraseña y regenera las credenciales de API del centro de clientes.
El analizador de Virtualizor busca los indicadores conocidos; la confianza en el sistema hay que reconstruirla aparte. Si aparecen indicios, el caso pasa a ser un ataque a la cadena de suministro con posible impacto en los clientes de cada máquina virtual, y ahí entran los plazos de notificación de NIS2 para quien esté en su ámbito. El equipo de respuesta a incidentes de Hard2bit se ocupa de ese tramo, el de acotar el alcance cuando el fabricante no puede decirte si estás en la lista.
Qué debe cambiar en quien distribuye software
TLS protege el canal, no el contenido. Un certificado válido demuestra que quien responde controlaba el dominio en el momento de la validación, y un secuestro de ruta convierte esa condición en algo que un tercero puede cumplir durante unas horas. La conclusión de BGPKIT es que, una vez cae el enrutamiento, solo la firma de paquetes en el cliente de actualización separa un incidente de red de un compromiso de la cadena de suministro.
Es el mismo razonamiento que ya hicimos con TeamPCP y las herramientas de seguridad troyanizadas y con el gusano de npm que plantaba ganchos en los editores. El mecanismo de distribución forma parte de la superficie de ataque del producto.
Si compras software con actualizaciones automáticas, la pregunta a cada proveedor es corta: ¿verifica el cliente la firma del paquete antes de instalarlo, o confía en HTTPS? En nuestro repaso de las cinco lecciones de la cadena de suministro digital esa pregunta ya aparecía; este incidente enseña lo que cuesta responderla mal. Para quien vende, la respuesta debe estar en la hoja de ruta antes de que un cliente haga la pregunta, y el bastionado de los sistemas que ejecutan el panel limita el daño cuando la respuesta llega tarde.
En toda la cadena faltaba un punto que comprobara el paquete en sí, y por ese hueco pasó una puerta trasera hasta el root de los hipervisores de un proveedor de hosting. Virtualizor ha prometido la firma de paquetes; mientras no llegue, cualquier producto cuyo cliente de actualización confíe en HTTPS está a un /24 mal filtrado de la misma cadena.
Sobre las fuentes y la atribución: este artículo se basa en el aviso público de Virtualizor, en la reconstrucción independiente de BGPKIT a partir de datos públicos de enrutamiento y en lo comunicado por operadores a medios especializados, con la información disponible a fecha de publicación. Que el anuncio partiera del sistema autónomo AS62390 no establece por sí solo quién lo operaba ni con qué intención, y ninguna mención implica un fallo de seguridad en las redes ni en las autoridades de certificación citadas, cuyo papel fue el de mecanismo abusado. Las cifras de impacto proceden de los afectados y pueden cambiar.
Este artículo tiene carácter divulgativo. Los pasos de comprobación y remediación descritos deben adaptarse a cada entorno y no sustituyen a un análisis forense cuando hay indicios de compromiso. Si sospechas que un servidor está afectado, busca apoyo especializado.
