HD Doctor Logo

Ransomware en Proxmox: Recuperar VMs y Discos QCOW2/ZFS

Por el Equipo Técnico HD Doctor

Respuesta directa

El ransomware en Proxmox rara vez destruye los datos. En la mayoría de los casos el atacante cifra solo los primeros megabytes de cada disco QCOW2 o zvol ZFS — el host queda inutilizable, pero del 80% al 95% de los bloques de las VMs siguen íntegros en el storage. La recuperación depende casi por completo de lo que se haga en las primeras horas.

Dónde ataca realmente el ransomware en Proxmox

Proxmox VE es Debian + KVM/LXC, así que el ransomware que lo alcanza es un binario Linux común — no existe un 'ransomware de Proxmox'. Hay dos caminos de entrada. (1) Compromiso del host: interfaz web en el puerto 8006 expuesta a internet, SSH con root habilitado, credencial reutilizada, o vulnerabilidad sin parche como el bypass de autenticación del advisory PSA-2026-00043-1 (CVE-2023-54391), explotado activamente desde septiembre de 2026. Con root en el host, el atacante cifra /var/lib/vz/images, los zvols ZFS, los volúmenes LVM-thin y el directorio /etc/pve. (2) Compromiso desde la VM: cuando un invitado recibió acceso directo al datastore (NFS montado sin restricción, passthrough de disco, share del host), el ransomware del invitado cifra sus propios vdisks. Un detalle cambia todo en la recuperación: familias modernas como BlackCat/ALPHV, LockBit, Play y Qilin usan cifrado intermitente — escriben solo el encabezado y bloques muestreados, para cifrar terabytes en minutos. En un QCOW2 de 500 GB, lo que muere es el encabezado (magic QFI, tablas L1/L2 y refcount); el resto de los clusters permanece en texto claro y es recuperable por reconstrucción o carving. Lo mismo vale para /etc/pve: es un sistema de archivos FUSE (pmxcfs) apoyado en SQLite en /var/lib/pve-cluster/config.db — recuperar ese archivo devuelve todos los .conf de las VMs, con el mapeo de discos.

Qué nunca hacer en un Proxmox cifrado

  1. 1.
    Reinstalar Proxmox sobre el disco afectado. La instalación recrea la tabla de particiones y el pool. Es la causa número uno de caso irrecuperable que habría llegado intacto al laboratorio.
  2. 2.
    Ejecutar zpool destroy o zpool import -f a ciegas. La importación forzada escribe en el pool y puede consumir los uberblocks antiguos que permitirían rollback de transacción. Siempre readonly=on primero.
  3. 3.
    Usar lvconvert --repair en el volumen original. La reparación de metadatos thin reescribe el mapeo. Hecha en el original y sin copia, convierte un caso de horas en caso perdido.
  4. 4.
    Restaurar backup sobre el storage alcanzado. Además de sobrescribir los bloques todavía íntegros, destruye la evidencia forense que sustenta dictamen, notificación al regulador y póliza de seguro.
  5. 5.
    Dejar el Proxmox Backup Server en la misma red y credencial. El atacante moderno busca el PBS antes de cifrar. Datastore alcanzable con la misma clave es datastore borrado. Namespaces, prune protegido y verificación son el mínimo.
  6. 6.
    Negociar rescate antes del inventario. En buena parte de los casos que atendemos existían snapshots ZFS o PBS intactos que nadie había revisado. Pagar sin inventario es pagar por dato que ya se tenía.

Cómo recuperar un Proxmox alcanzado por ransomware, en 7 pasos

Secuencia usada por HD Doctor en entornos virtualizados. Los pasos 1 a 3 son irreversibles si se saltan — ahí es donde se pierde la mayoría de los casos.

  1. 1

    Aísle el host sin apagarlo

    Desconecte el cable de red o bloquee el tráfico en el switch. No reinicie ni apague: la RAM aún puede contener claves, procesos del encryptor y evidencia del origen del ataque. El reinicio también dispara replay de journal en ZFS y LVM-thin, que sobrescribe metadatos todavía aprovechables.

  2. 2

    No reinstale, no repare, no pruebe

    Reinstalar PVE encima, ejecutar zpool destroy, forzar lvconvert --repair o restaurar backup sobre el storage afectado son las cuatro acciones que más destruyen casos recuperables. En esta fase el host es evidencia y medio de origen, nada más.

  3. 3

    Imagen bit a bit antes de cualquier intento

    Clone cada disco físico con ddrescue o hardware de imagen hacia storage externo, con hash SHA-256 del original y de la copia. Todo el trabajo siguiente ocurre sobre la copia. En ZFS, importe siempre con zpool import -o readonly=on. Sin imagen, cada intento de reparación consume una oportunidad.

  4. 4

    Inventaríe lo que sobrevivió

    Sobre la copia: qemu-img info y qemu-img check en cada .qcow2 para ver si el encabezado está intacto; zfs list -t snapshot -o name,creation para listar snapshots; verificar si el datastore del Proxmox Backup Server fue alcanzado; localizar /var/lib/pve-cluster/config.db. Ese inventario decide el camino: restore limpio, rollback o reconstrucción en laboratorio.

  5. 5

    Agote las opciones de ZFS antes de reconstruir

    Los snapshots ZFS son read-only por diseño: un encryptor que escribe en el dataset no altera el snapshot anterior. Si los snapshots existen, un clone (no rollback) sobre la copia devuelve las VMs en minutos. Si el pool no importa, intente importación read-only con -F y, en último caso, rollback de transacción con zpool import -T <txg> — operación que solo debe hacerse sobre imagen, nunca en el disco original.

  6. 6

    Reconstruya QCOW2, zvol y LVM-thin cifrados parcialmente

    Con encabezado QCOW2 destruido pero clusters íntegros, reconstruimos header, tablas L1/L2 y refcount a partir de la geometría del archivo, o extraemos el filesystem interno por carving. En disco raw y zvol el camino es más directo: el NTFS o ext4 interno suele ser remontable desde MFT espejada o superbloque de respaldo. En LVM-thin, los metadatos vienen de thin_dump sobre la copia y de /etc/lvm/archive vía vgcfgrestore.

  7. 7

    Reconstruya en hardware limpio y solo entonces reconecte

    Instale un Proxmox nuevo en hardware o discos distintos, restaure las VMs validadas, corrija el vector de entrada (parche, 8006 fuera de internet, MFA, credenciales rotadas) y solo después reconecte a la red. Encender el host comprometido 'para ver si funciona' es reinfección garantizada, ahora sin copia limpia.

Preguntas frecuentes

¿Se puede recuperar un disco QCOW2 cifrado por ransomware?

En la mayoría de los casos, parcial o totalmente — sin pagar rescate. Como las familias actuales usan cifrado intermitente, lo que suele destruirse es el encabezado QCOW2 y las tablas de asignación, no los datos. Reconstruyendo el encabezado o haciendo carving de los clusters íntegros, se recuperan bases de datos, archivos y VMs enteras. Si el encryptor cifró el archivo de principio a fin, solo backup, snapshot o decryptor válido resuelven.

¿El ransomware puede cifrar los snapshots ZFS de Proxmox?

Cifrar, no: los snapshots ZFS son inmutables por construcción. Pero quien tiene root en el host puede destruirlos con zfs destroy, y es lo que suele ocurrir antes del cifrado. Si el pool aún existe, incluso con snapshots eliminados hay chance real de rollback de transacción (zpool import -T) mientras haya poca escritura nueva — otro motivo para no reiniciar ni reinstalar.

Mi Proxmox Backup Server también fue cifrado. ¿Todavía hay salida?

Sí. El datastore de PBS es un chunk store: incluso con parte de los chunks dañada, un verify job identifica qué snapshots aún restauran íntegramente. Y el storage del propio PBS es recuperable en laboratorio como cualquier volumen ZFS o ext4 cifrado parcialmente. No formatee ni ejecute garbage collection después del ataque.

El ataque vino desde dentro de una VM. ¿Cambia la recuperación?

Cambia el alcance. Si el invitado tenía acceso directo a los vdisks (NFS abierto, passthrough, share del host), solo las VMs alcanzadas fueron cifradas — host, /etc/pve y los demás datastores suelen estar limpios, lo que hace la recuperación mucho más rápida. También cambia la corrección: el problema es aislamiento de storage, no la contraseña del host.

¿Cuánto demora la recuperación de un Proxmox alcanzado?

Diagnóstico en hasta 24h. Cuando existen snapshots ZFS o PBS íntegros, el entorno suele volver en 24 a 72h. La reconstrucción de QCOW2 o LVM-thin cifrados parcialmente lleva de 3 a 10 días hábiles, según volumen y cantidad de VMs. Los casos con plazo crítico entran en régimen de emergencia 24×7.

¿Necesito enviar el servidor entero o solo los discos?

En general solo los discos, en el orden e identificación originales — fotografíe las bahías antes de retirarlos. Si el storage es Ceph o el cluster perdió quórum, evaluamos nodo por nodo, y en algunos casos conviene atención remota sobre imágenes que su equipo genera in situ, con nuestra supervisión.

¿HD Doctor entrega dictamen para seguro y autoridad de datos?

Sí. Todo caso de ransomware sale con informe técnico, hashes SHA-256 de origen y copia y cadena de custodia documentada — material aceptado por aseguradoras, peritaje judicial y notificación de incidente a la autoridad de protección de datos.

¿Proxmox cifrado ahora? No reinicie el host.

Diagnóstico en 24h, atención de emergencia 24×7, NDA antes del envío. 280+ entornos Proxmox atendidos.

Próximas lecturas