Por qué parte del VMDK suele sobrevivir
Los ESXi-cryptors modernos optimizan para velocidad: cifrar 50 TB completamente toma horas. Para un ataque que necesita ser rápido (antes de detección), los operadores cifran solo los primeros megabytes de cada VMDK — lo suficiente para destruir el encabezado VMFS y hacer el disco inaccesible por montaje normal. Los datos internos de la VM (NTFS dentro del VMDK) suelen permanecer intactos. La recuperación técnica explota eso.
Errores catastróficos en recuperación ESXi
- 1.Intentar fix-vmfs en el datastore original. Los comandos de reparación de ESXi intentan reescribir metadatos. Ejecutar con datastore parcialmente cifrado destruye lo que aún era legible.
- 2.Borrar VMDKs cifrados pensando que 'solo estorban'. Aun cifrados, el contenido interno puede extraerse. Borrar es irreversible.
- 3.Restaurar VM en datastore antiguo. El datastore comprometido tiene persistencia. Use storage limpio.
- 4.Ignorar logs vCenter post-incidente. Los logs del vCenter muestran quién logueó, cuándo, de qué IP. Crítico para forense y para evitar reinfección.
Flujo de recuperación en 5 pasos
- 1
Snapshot del datastore entero ANTES de cualquier acción
Conecte el storage del datastore en ambiente aislado read-only o cree snapshot LUN en el SAN. Trabaje siempre en copia, nunca en el original. El encabezado cifrado puede ser único — perderlo = inviabiliza el intento.
- 2
Identifique los límites de VMDK en el datastore
Sin el encabezado VMFS funcional, parsing manual con herramientas como UFS Explorer Professional, R-Studio o DMDE. Cada archivo VMDK comienza con magic number y está alineado en bloques de 1 MB.
- 3
Extraiga contenido bruto de los VMDKs identificados
Aun sin montar normalmente, las herramientas profesionales leen el contenido bruto. Resultado: imagen dd del disco virtual interno (generalmente NTFS, ext4 o XFS para Linux VMs).
- 4
Recupere archivos dentro del filesystem
La imagen dd del paso 3 puede montarse con testdisk, photorec o herramientas forenses. El NTFS interno suele estar intacto. Base SQL Server, archivos de aplicación, historia clínica extraíbles.
- 5
Reconstruya VMs en ambiente nuevo
No restaure en la infraestructura comprometida. Provea vCenter nuevo, ESXi limpio, cree VMs nuevas y migre los archivos recuperados. Hardening simultáneamente (pasos del post de hardening Windows).
Preguntas frecuentes
¿Cuál es la tasa de éxito de recuperación ESXi post-ransomware?
Variable por caso. Con snapshot del datastore intacto + cifrado parcial (solo encabezado): 70-90% de los datos internos recuperables. Cifrado total o storage físico comprometido: 20-40%. Sin backup, la recuperación técnica del datastore es la única alternativa antes de considerar pago.
¿Cuánto tiempo toma?
Datastore de 10 TB: 3-7 días hábiles. 50 TB: 10-20 días hábiles. El tiempo depende de la complejidad del filesystem interno de las VMs y cantidad de VMs.
¿Puedo hacerlo yo sin laboratorio?
Técnicamente sí con UFS Explorer Professional (~US$ 1.500 licencia), pero la curva de aprendizaje es alta. Los errores destruyen datos. Para caso corporativo crítico, el laboratorio especializado es más barato considerando el riesgo de error.
¿Y si el storage físico SAN también fue atacado?
Caso más complejo. Si el SAN tiene snapshot de array-level (NetApp, Pure, Dell EMC) pre-incidente intacto, puede restaurarse. Sin snapshot, la recuperación física del SAN es necesaria.
¿El backup Veeam logra restaurar post-ataque?
Si el backup era inmutable (Hardened Repository / Object Lock) y no fue alcanzado por el atacante: sí, restaurar en ambiente nuevo. Si el backup mutable también fue cifrado: necesita recuperar el storage.
¿Datastore ESXi cifrado por ransomware?
Especialistas VMware. Snapshot de preservación en hasta 6h. Cadena de custodia documentada.