Virtualizor confirmó que un secuestro de rutas BGP permitió a un atacante distribuir una actualización maliciosa a instalaciones de su panel de virtualización. El incidente desvió tráfico destinado a infraestructura de Softaculous entre el 28 de agosto de 2026 a las 20:57 UTC y el 30 de agosto a las 06:10 UTC. Durante las oleadas activas, el desvío llegó aproximadamente al 72% de los 368 peers observados por RIPE RIS.
El problema no fue una advertencia teórica: Virtualizor reconoce que algunas instalaciones descargaron el paquete manipulado. Proveedores afectados documentaron modificaciones en archivos legítimos, una llave SSH para root, una cuenta no autorizada, persistencia mediante systemd y una sesión interactiva del atacante.
Acción inmediata: todo operador de Virtualizor debe revisar sus nodos, aunque no recuerde haber actualizado manualmente. No reinicies Virtualizor ni borres indicadores antes de preservar evidencia. Si confirmas compromiso con privilegios
root, una limpieza no sustituye la reconstrucción del hipervisor.
Resumen del incidente de Virtualizor
| Dato | Información confirmada |
|---|---|
| Ventana completa | 28 de agosto, 20:57 UTC, al 30 de agosto, ~06:10 UTC: unas 33.3 horas |
| Desvío activo | Dos oleadas que sumaron aproximadamente 22 horas, separadas por unas 11 horas de desvío casi nulo |
| Prefijo secuestrado | 162.55.80.0/24, dentro de infraestructura de Softaculous alojada en Hetzner |
| Ruta observada | AS62390 (NexonHost), mediante AS6204 (Zet.net), conservando AS24940 (Hetzner) al final del AS path |
| Alcance en RIPE RIS | Los 368 de 368 peers transportaron la ruta secuestrada en algún momento |
| Pico durante las oleadas | Mediana de 266 peers desviados; aproximadamente 72% del conjunto completo de 368 |
| Promedio temporal | ~28% de los 368 peers y ~65% de los peers con una ruta /24, según Virtualizor |
| Impacto confirmado | Un paquete malicioso de Virtualizor llegó a un número pequeño, todavía indeterminado, de instalaciones |
| Fallo de control | El cliente de actualización no verificaba criptográficamente los paquetes |
| Estado de la ruta | Restaurada; no se observó desvío después del 30 de agosto a las 06:10 UTC en los datos citados |
Cómo funcionó el BGP hijack
Hetzner anunciaba normalmente el bloque amplio 162.55.0.0/16. El atacante anunció el prefijo más específico 162.55.80.0/24. En BGP, una ruta más específica suele tener prioridad, por lo que las redes que aceptaron el anuncio enviaron hacia el atacante el tráfico destinado a esas direcciones.
El anuncio comenzó aproximadamente a las 20:57 UTC del 28 de agosto. La primera oleada se mantuvo hasta alrededor de las 08:50 UTC del día 29, cuando Hetzner empezó a anunciar directamente el /24 como contramedida. Después de una pausa de unas once horas, el anuncio no autorizado reapareció cerca de las 20:00 UTC y continuó hasta aproximadamente las 06:00 UTC del 30 de agosto.
Virtualizor reconstruyó el evento con RIPE BGPlay y RIPE RIS. La ruta fue muy inestable: el proveedor contabiliza alrededor de 10,600 withdrawals. Por eso una máquina solamente recibía el paquete malicioso si su comprobación de actualización coincidía con un intervalo en el que su red estaba desviada y la descarga terminaba.
Por qué HTTPS no detuvo el ataque
El servidor impostor obtuvo un certificado TLS técnicamente válido de Let’s Encrypt. La validación automatizada de control de dominio también pasó por la ruta secuestrada, así que la autoridad certificadora llegó al sistema del atacante. Para un cliente afectado, el certificado era válido y no aparecía una advertencia TLS.
El certificado cubría dominios de Virtualizor y del ecosistema Softaculous, incluidos virtualizor.com, api.virtualizor.com y files.virtualizor.com. Además del endpoint de actualizaciones, el rango afectado atendía el área de clientes y facturación. Virtualizor advierte que una sesión iniciada en softaculous.com/clients durante la ventana pudo ser desviada.
El punto crítico: las actualizaciones no estaban verificadas criptográficamente
Virtualizor admite que su cliente de actualización todavía no verificaba criptográficamente los paquetes. El TLS válido protegía una conexión con el destino al que BGP había llevado al cliente, pero no garantizaba que el archivo descargado fuera una versión auténtica firmada por el proveedor.
Esta diferencia es central: HTTPS protege el transporte; una firma de artefacto permite verificar el origen e integridad del paquete incluso si DNS, BGP, un mirror o parte de la red fallan. Sin esa segunda comprobación, el cliente aceptó el paquete que respondió desde la infraestructura del atacante.
Alcance real: qué sabemos y qué todavía no
Virtualizor habla de “un pequeño número” o “un puñado” de servidores afectados, pero no puede producir una lista definitiva porque las respuestas maliciosas nunca llegaron a sus propios registros. Por ello, “pocos confirmados” no significa que el resto pueda declararse limpio sin revisar.
En LowEndTalk, un proveedor informó que encontró los mismos cambios maliciosos en 5 de sus 34 hipervisores. En uno de ellos, el cron legítimo virt_check.php comenzó a las 22:23:01 CEST del 29 de agosto y la llave SSH del atacante fue creada en el mismo segundo. Minutos después apareció el usuario proxyuser y se registró una sesión SSH de unas tres horas y quince minutos.
Hasta el momento no existe una cifra global verificable de operadores, hipervisores o VPS de clientes afectados.
Diagnóstico rápido: cómo saber si tu Virtualizor está infectado
Ejecuta estas comprobaciones como una primera triage. No borres nada todavía; conserva salida, fechas, hashes y copias de los archivos sospechosos.
sudo test -e /etc/systemd/system/java-jre-update.service && echo "IOC: servicio encontrado"
sudo systemctl status java-jre-update.service --no-pager
sudo getent passwd proxyuser
sudo pgrep -af 'java|jre-runtime|widdow'
sudo ss -tpna | grep -E '31\.77\.220\.138|:2025'
Virtualizor publica como indicador conocido /etc/systemd/system/java-jre-update.service. Los proveedores añadieron los siguientes IOC:
- Payload:
/usr/lib/jvm/.cache/jre-runtime.dat - SHA-256:
b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7 - Descarga:
cdn.nerat.cc/installer/widdow.jar - Usuario:
proxyuser - Conexión observada:
31.77.220.138:2025 - Origen SSH observado:
193.32.127.248 - Marcadores:
/usr/lib/jvm/.cache/.installedy/tmp/.vz_svc_done
Busca esos indicadores y revisa los tres archivos de Virtualizor donde se observaron comandos inyectados:
Recupera tus servicios en infraestructura bajo tu control
Si necesitas reconstruir cargas afectadas, un VPS te permite separar servicios, controlar la red y mantener respaldos externos.
sudo grep -RsnE 'cdn\.nerat\.cc|widdow\.jar|jre-runtime\.dat|proxyuser|AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte' /usr/local/virtualizor /etc/systemd/system /root/.ssh 2>/dev/null
sudo stat /usr/local/virtualizor/_universal.php /usr/local/virtualizor/globals.php /usr/local/virtualizor/zzvirtservice
sudo sha256sum /usr/lib/jvm/.cache/jre-runtime.dat 2>/dev/null
Una coincidencia es evidencia suficiente para aislar y escalar el incidente. La ausencia de estos IOC no demuestra que el host esté limpio: el atacante obtuvo acceso interactivo y pudo dejar otros usuarios, llaves, cron jobs, servicios o binarios.
El script oficial de Virtualizor: para qué sirve y qué no garantiza
Virtualizor publicó virtualizor_security_scan.sh como herramienta de escaneo y limpieza. Antes de ejecutarlo como root, descárgalo y revísalo:
curl -fsSLO https://files.virtualizor.com/security/virtualizor_security_scan.sh
less virtualizor_security_scan.sh
sudo bash virtualizor_security_scan.sh
El script puede localizar o retirar artefactos conocidos, pero no puede demostrar que no exista persistencia adicional. Tampoco convierte en confiable un sistema donde ya se ejecutó malware como root. Si aparece un IOC, contacta al proveedor, preserva evidencia y planifica una reconstrucción desde medios conocidos.
Qué hacer si encuentras indicadores
- Aísla el nodo de redes de administración y limita el tráfico saliente sin destruir evidencia.
- No reinicies
zzvirtserviceantes de inspeccionarlo: un archivo infectado puede volver a ejecutar el payload. - Captura evidencia: archivos, metadatos, procesos, conexiones, journal, auth logs, cron, usuarios y llaves SSH.
- Rota secretos desde un equipo limpio: API keys de master y slaves, root/SSH, base de datos, backups, panel, facturación y credenciales accesibles desde el host.
- Trata los datos accesibles como potencialmente expuestos. Evalúa notificación a clientes y obligaciones regulatorias.
- Reconstruye el hipervisor desde una fuente limpia. Borrar el JAR y el servicio no restablece la confianza.
- Revisa los guests y restaura solamente desde respaldos cuya fecha e integridad puedas justificar.
Qué hacer aunque no encuentres el servicio malicioso
- Revisa si el nodo buscó o instaló actualizaciones durante la ventana del incidente.
- Regenera las API keys de Virtualizor y limita cada una a IP confiables.
- Audita llaves SSH, usuarios nuevos, cron, systemd, conexiones salientes y logs de actualización.
- Restringe el panel y SSH a una red de administración, VPN o allowlist.
- Cambia la contraseña del área de clientes de Softaculous si se utilizó durante la ventana y regenera sus API keys.
- Si introdujiste datos de tarjeta, revisa movimientos; Softaculous afirma que el procesamiento ocurre en pasarelas externas.
Lecciones para operadores de hosting
El incidente combina tres dependencias que no deben tratarse como una sola garantía: enrutamiento BGP, autenticación TLS e integridad del software. RPKI/ROV y anuncios defensivos más específicos reducen parte del riesgo de rutas; Certificate Transparency permite detectar certificados inesperados; y las actualizaciones firmadas ofrecen una última comprobación independiente del transporte.
También refuerza la necesidad de separar la red de administración, centralizar logs fuera del hipervisor, mantener inventario de llaves y disponer de procedimientos de reconstrucción probados. Un respaldo de las máquinas virtuales es importante, pero no sustituye un plan para recuperar el plano de control.
Preguntas frecuentes
¿Virtualizor fue hackeado?
Virtualizor confirma que un BGP hijack desvió tráfico y entregó un paquete malicioso a algunas instalaciones. El término preciso es un compromiso de la cadena de distribución mediante secuestro de rutas, facilitado por la falta de verificación criptográfica de paquetes.
¿Todos los servidores Virtualizor están infectados?
No. El paquete llegó solamente cuando una comprobación coincidió con un intervalo desviado y completó la descarga. Sin embargo, Virtualizor no puede listar todos los afectados y pide revisar cada instalación.
¿El script oficial garantiza que el servidor quede limpio?
No. Ayuda con IOC conocidos, pero no descarta persistencia adicional después de acceso root.
Conclusión
Este no fue un simple fallo del panel. Un anuncio BGP no autorizado alcanzó todos los peers de RIPE RIS en algún momento, permitió obtener un certificado TLS válido y colocó una actualización maliciosa frente a clientes que no verificaban criptográficamente los paquetes. El número confirmado de servidores es pequeño, pero el total real sigue sin conocerse.
Comprueba los IOC, preserva evidencia y no confundas una limpieza rápida con recuperación forense. Para reconstruir servicios en infraestructura separada y con control de red, backups y acceso root, revisa el VPS Hosting de Teramont.
