22 nodos Proxmox hackeados: lo que no vio la recuperación

Al parecer, un clúster Proxmox de 22 nodos fue comprometido después de que un entorno Proxmox VE 7.4, ya fuera de soporte, siguiera accesible desde internet en el puerto 8006. La intrusión ya fue bastante grave, pero a mí me parece más instructivo lo que pasó después: reconstruir los hosts dejó algunos puntos de apoyo intactos, y los atacantes volvieron en cuanto se restableció el servicio.

Todo el mundo se quedará con "aplica los parches y no expongas la gestión del hipervisor a internet", y hacen bien. Lo menos evidente es que recuperar un sistema en clúster tras un compromiso de root exige mucho más que restaurar archivos desde una copia de seguridad. Un kernel comprometido puede mentir a tus herramientas de recuperación, y el estado compartido del clúster puede mantener vivas las credenciales del atacante aunque reconstruyas un nodo. Los agentes de invitado convierten el root del hipervisor en root de la VM invitada, y las copias de seguridad pueden salvar la plataforma mientras el plano de control sigue contaminado. En este incidente coincidieron todos esos fallos.

¿Qué le pasó al clúster Proxmox de 22 nodos?

El informe del incidente que publicó Netfront dice que al menos 33 direcciones externas obtuvieron root en su clúster Proxmox VE de 22 nodos entre el 1 y el 2 de septiembre de 2026.

La zona afectada seguía en Proxmox VE 7.4, que llegó al fin de su vida útil en julio de 2024. El puerto 8006 era accesible desde internet porque los clientes usaban la interfaz de Proxmox para gestionar sus máquinas virtuales.

El punto de entrada fue CVE-2023-54391. Afecta a las versiones de libpve-access-control desde la 7.0-7 hasta la 8.0.4, sin incluir esta última. Un atacante que llegue a la API de inicio de sesión puede abusar del flujo de desafío de doble factor para obtener un ticket válido de cualquier cuenta habilitada que no tenga configurado un segundo factor.

El código vulnerable ya había desaparecido de los paquetes más recientes de Proxmox en julio de 2023. Nadie se dio cuenta de su impacto en la seguridad ni lo documentó públicamente hasta septiembre de 2026.

Netfront cuenta que su primera petición anómala llegó unos 25 minutos después de que se publicara el aviso de Proxmox, y que la primera shell de root confirmada apareció más tarde esa misma noche. A partir de ahí todo se aceleró, y al parecer los registros mostraron varias fuentes independientes recorriendo toda la flota. Una dirección abrió exactamente una shell en cada uno de los 22 nodos en poco más de un minuto, y otra acumuló casi 2,000 sesiones de shell en el clúster a lo largo de un día.

El informe dice sin rodeos que aquello no parecía obra de un único operador coordinado: cuando se publica un bypass de autenticación fácil, un plano de gestión vulnerable puede atraer a la vez a varios atacantes sin relación entre sí.

¿Por qué comprometer un nodo Proxmox ponía en peligro los 22?

Un clúster Proxmox está diseñado para compartir entre nodos estado sensible del plano de control.

Proxmox usa pmxcfs, su sistema de archivos distribuido del clúster, montado en /etc/pve. Replica la configuración del clúster para que todos los nodos vean los mismos usuarios, definiciones de VM, configuración del firewall, certificados, ajustes de HA y el resto del estado común del clúster. Uno de los archivos protegidos es /etc/pve/priv/authorized_keys, que Proxmox usa para la autenticación SSH entre miembros del clúster.

Netfront sostiene que esto facilitó mucho la propagación a toda la flota una vez que los atacantes tuvieron root en un host. Los miembros de un clúster necesitan una forma de confianza para hablar entre sí y compartir configuración, así que eso por sí solo no es un defecto de diseño, pero cambia cómo respondes. Tener root en un hipervisor en clúster es una situación distinta a tener root en un servidor Linux aislado, porque entran en juego todas las relaciones de confianza que unen ese nodo con el resto del clúster.

Si estás diseñando o revisando un clúster, el hub de Proxmox de Mr.PlanB explica cómo interactúan las redes, el almacenamiento, la HA y el estado del clúster, lo cual resulta más útil que mirar cada host por separado.

¿Por qué los hosts parecían tener hardware averiado?

El informe del incidente cuenta que un rootkit eBPF hizo que los nodos comprometidos se comportaran tan mal que el equipo se puso primero a buscar problemas de hardware. Entre los síntomas había cargas medias de entre 30 y 160 en sistemas que por lo demás estaban inactivos, comandos que se detenían sin motivo y herramientas como top que se caían.

La verificación de paquetes no encontró la causa enseguida, porque los binarios legítimos no tenían por qué haber sido reemplazados. La interceptación ocurría dentro del kernel. Al parecer, el rootkit enganchaba llamadas al sistema para ocultar procesos y archivos, bloquear la inspección, proteger sus propios procesos y alterar lo que veían las herramientas de espacio de usuario. Netfront vinculó partes de él con código público de prueba de concepto para eBPF y no lo describió como un rootkit privado sofisticado.

Esa parte me incomoda. Los atacantes ya no tienen que inventar sus técnicas de ocultación, porque el código de investigación público abarata construir algo difícil de investigar desde dentro del host. No hace falta que te pongas a buscar rootkits exóticos en cada servidor con carga, pero sí tienes que dejar de fiarte de lo que un host dice de sí mismo en cuanto un compromiso a nivel de kernel sea plausible.

¿Cómo llegaron los atacantes a las VM de los clientes?

Netfront dice que los atacantes usaron el QEMU Guest Agent desde los hosts Proxmox comprometidos, y yo pondría ese dato cerca del principio de la lista de cosas que merece la pena recordar.

El agente de invitado gestiona la comunicación entre el host y la VM invitada. Proxmox lo usa para apagar invitados, congelar y descongelar el sistema de archivos, informar de direcciones IP y ejecutar comandos. Tras un compromiso del host, esa comodidad le da al atacante mucho poder.

Según el informe, los registros de la API mostraban comandos ejecutándose dentro de las VM invitadas mediante agent/exec, con la salida recogida a través de agent/exec-status. No hacía falta ninguna contraseña del invitado, porque el hipervisor ya tenía autoridad para pedir esas acciones a través del agente. Los invitados con el QEMU Guest Agent activado se vieron afectados, y a los que no lo tenían no se llegó por esta vía.

Yo no lo leería como un consejo para desactivar el agente de invitado en todas partes, ya que hace trabajo operativo legítimo. Aun así, el root del hipervisor ocupa una posición con muchísimos privilegios sobre cada invitado, y las contraseñas fuertes en los invitados no son una frontera de seguridad real frente a un hipervisor totalmente comprometido. Protege el plano de gestión teniendo esto en cuenta.

¿Por qué falló la primera restauración?

El equipo restauró el sistema de archivos mientras el kernel comprometido seguía en marcha. Netfront dice que su primer intento de recuperación usó:

rsync -aHAX --delete

para restaurar datos limpios sobre un host infectado. El comando terminó, y el rootkit sobrevivió.

El informe explica por qué. El rootkit interceptaba el listado de directorios, y rsync --delete necesita listar los archivos del destino para saber qué borrar. Si el kernel oculta un archivo malicioso en ese listado, rsync nunca sabe que el archivo está ahí, así que no lo borra. Una copia de seguridad perfectamente limpia puede terminar en una restauración fallida, porque es un sistema operativo comprometido el que le dice a la herramienta de recuperación qué existe en el destino.

Netfront cambió el proceso: eliminar el rootkit, reiniciar, restaurar, volver a reiniciar y después validar. Los hosts que no arrancaban de forma fiable se reconstruyeron desde medios externos, donde el kernel comprometido no se ejecutaba en absoluto. Tras un compromiso profundo del host, esa vía externa es el modelo más seguro. Si tienes motivos para pensar que el kernel ha sido subvertido, desconfía de cualquier restauración hecha desde dentro de él.

¿Por qué volvieron a entrar los atacantes después de la reconstrucción?

Los hosts se reconstruyeron, pero el plano de control compartido del clúster seguía guardando credenciales que habían creado los atacantes. Para mí es la parte más útil de la historia.

Netfront dice que rotó contraseñas, claves SSH y el contenido de partes de /etc/pve/priv/. Al principio no enumeró por completo los tokens de API ni comparó cada cuenta con una lista de referencia de las identidades que debían existir. Ese hueco importó porque /etc/pve es el sistema de archivos vivo del clúster Proxmox, replicado entre nodos, así que reconstruir un host no hace nada contra el estado malicioso que el clúster sigue copiando de vuelta.

Según el informe, la auditoría posterior de la empresa encontró 42 tokens de API asociados a root@pam y diez cuentas falsas con nombres que imitaban a las legítimas. El 7 de septiembre, con la plataforma ya de nuevo en servicio, se volvieron a usar credenciales que habían sobrevivido a la reconstrucción.

Un nodo limpio puede volver a unirse a un plano de control sucio, así que cuando se compromete una plataforma en clúster, la recuperación necesita su propia auditoría de la configuración compartida, las credenciales, los tokens, las ACL, las cuentas de automatización, los certificados, la confianza SSH y todo lo demás que se replique fuera del sistema de archivos del host.

Un Proxmox Health Check puede detectar problemas de configuración corrientes, pero una revisión tras un compromiso necesita una auditoría de identidades y de confianza mucho más agresiva.

¿Qué hizo bien el diseño de las copias de seguridad?

De todo el diseño, lo que mejor aguantó fue la separación entre la infraestructura de producción y la de backup.

Netfront dice que sus sistemas de backup extraían los datos de los hosts de producción, de modo que producción nunca enviaba datos al destino de las copias ni lo administraba. Por tanto, la zona afectada no tenía credenciales capaces de borrar sus copias de recuperación remotas. La empresa también guardaba copias entre zonas en edificios distintos.

Eso coincide con las recomendaciones de Proxmox Backup Server. Proxmox recomienda copias en otra ubicación y permisos de backup restrictivos, advierte expresamente contra dar privilegios de borrado a los clientes de backup y recomienda probar restauraciones de forma periódica en vez de suponer que unos trabajos de backup correctos demuestran que puedes recuperar.

La replicación no es automáticamente una copia de seguridad. Si un sistema de producción comprometido puede autenticarse en la copia, modificarla y borrarla, el atacante puede llegar a destruir a la vez la producción y los datos de recuperación. Una copia de seguridad que valga la pena está detrás de una frontera de confianza que producción no puede cruzar a la ligera, así que la recuperación, aunque siga siendo un trabajo duro, parte de algo en lo que puedes confiar.

¿El verdadero error fue usar Proxmox VE 7.4?

Fue uno de varios errores. La reacción de la comunidad fue inusualmente unánime en dos puntos: el entorno usaba una versión del hipervisor fuera de soporte y su interfaz de gestión era accesible públicamente. Cada uno aumenta el riesgo, y juntos lo multiplican.

En el debate también se planteó una cuestión razonable sobre por qué los equipos de producción dudan ante las actualizaciones mayores del hipervisor. Una infraestructura estable, bien conocida y que da servicio a clientes no se puede actualizar a la ligera. Actualizar de inmediato sin probar también es arriesgado, así que necesitas un proceso de parches que te permita probar las actualizaciones mayores antes de que la versión actual se convierta en una emergencia sin soporte.

Un laboratorio o un entorno espejo representativo, procedimientos de marcha atrás documentados, ventanas de mantenimiento, comprobaciones de compatibilidad de hardware, pruebas con los invitados y actualizaciones escalonadas de nodos cuestan tiempo. También cuesta tiempo reconstruir 22 hipervisores comprometidos. Saltarse el proceso de actualización significa pagar ese coste más tarde, con un calendario que la organización ya no controla.

¿Debería estar alguna vez el puerto 8006 de Proxmox expuesto a internet?

Evita la exposición directa salvo que tengas un motivo inusualmente sólido y una arquitectura de seguridad que lo compense.

La interfaz de Proxmox es el plano de gestión del hipervisor, y nada en ella es de bajo privilegio. Por eso las críticas más duras del debate fueron para la exposición directa del puerto 8006 a redes no confiables, y no iban dirigidas a Proxmox en sí. Hay opciones mejores, como una VLAN de gestión, una VPN, un jump host dedicado, un proxy con control de identidad, reglas de firewall muy restringidas y MFA.

El autoservicio para clientes lo complica, porque los usuarios externos pueden necesitar legítimamente algunas funciones de gestión. Aun así, no necesitan acceso de red directo a todo el plano de control del hipervisor. Un portal de clientes aparte que use permisos de la API de Proxmox de alcance muy limitado es una opción, y un proxy de acceso con controles de identidad fuertes es otra.

Elijas lo que elijas, da por hecho que el código de autenticación puede tener fallos, y diseña de forma que un único bypass de autenticación no baste para conseguir root en todos los hipervisores.

¿Qué debe incluir una lista de recuperación de Proxmox tras un compromiso de root?

El incidente apunta a una lista de comprobación mucho más amplia que "restaurar desde la copia de seguridad":

• Reconstruye desde medios de confianza cuando sea posible que el kernel esté comprometido.
• Trata como sospechoso cada nodo del dominio de confianza.
• Audita /etc/pve como un plano de control compartido aparte.
• Enumera todos los usuarios y todos los tokens de API.
• Contrasta las ACL con un diseño que sepas que es correcto.
• Rota contraseñas, claves SSH, certificados y credenciales de servicio.
• Revisa la actividad del agente de invitado e inspecciona los sistemas invitados si el hipervisor comprometido podía ejecutar código dentro de ellos.
• Verifica las copias de seguridad desde un entorno que los hosts comprometidos no pudieran alterar.
• Envía los registros fuera del clúster para que los atacantes no puedan borrar el único historial útil.
• Prueba la interfaz de gestión desde internet y confirma que no es accesible salvo que esté protegida a propósito.

Sobre todo, no limites la búsqueda al mecanismo de persistencia que ya has visto. El informe de Netfront describe decenas de tokens y cuentas plantados, muchos de ellos sin usar nunca, y una puerta trasera dormida sigue siendo una puerta trasera.

Una reconstrucción impresionante que no debería haber hecho falta

El trabajo de recuperación de este incidente tiene verdadero valor técnico. La investigación relacionó el comportamiento extraño de los hosts con un rootkit eBPF, y el equipo descubrió un modo de fallo en la recuperación in situ con rsync. También recuperaron hosts que no arrancaban, conservaron copias utilizables gracias a la arquitectura de backup entre zonas y después reconstruyeron con bastante detalle la actividad de los atacantes a partir de los registros.

Aun así, una recuperación heroica es una mala estrategia de seguridad. Veintidós hipervisores fuera de soporte con un plano de gestión público permitieron que un solo bypass de autenticación se convirtiera en un incidente en toda la flota, y restaurar los hosts sin auditar a fondo las credenciales compartidas del clúster abrió una segunda puerta.

La mejor configuración es aburrida: software con soporte, acceso restringido a la gestión, MFA, copias de seguridad independientes, registros fuera del clúster, actualizaciones probadas, un inventario completo de identidades y procedimientos de recuperación que asuman que un host comprometido puede mentir. Nada de eso da para una buena batallita, y no pasa nada.