VMDK Data Recovery After an Akira Ransomware Attack

Las doce unidades fueron duplicadas mediante imágenes dentro de las 24 horas posteriores a su llegada, y todas las operaciones posteriores se ejecutaron sobre dichas imágenes. Los soportes originales permanecieron tal como se recibieron durante todo el proceso, lo que permitió preservar el estado probatorio mientras avanzaba el análisis.

Escanear aproximadamente 120 TB de una sola imagen a la vez no habría sido viable. Los ingenieros dividieron el trabajo en rangos de un terabyte y ejecutaron diez análisis de forma simultánea, lo que llevó el rendimiento a los límites propios del hardware. Posteriormente, se creó un segundo conjunto de imágenes en un segundo sistema, de modo que las extracciones pudieran realizarse en ambas máquinas de forma simultánea.

A medida que se eliminaban los datos, BTRFS había comenzado a borrar la capa que asigna los datos almacenados a sus ubicaciones físicas. Aproximadamente 7 TB de ese mapa se vieron afectados, lo que producía resultados inutilizables a partir de un almacenamiento por lo demás legible. Los ingenieros determinaron que las regiones afectadas habían sido asignadas de forma contigua antes de la eliminación, lo que hizo posible la reconstrucción manual. Reconstruir el mapa a mano restableció el acceso a aproximadamente 5 TB de datos de copia de seguridad que el sistema de archivos ya había liberado.

Un archivo VMDK dañado rara vez es simplemente legible o ilegible. Los ingenieros separaron las regiones intactas de aquellas que estaban cifradas, dañadas, parcialmente sobrescritas o estructuralmente comprometidas. Las tres máquinas de mayor prioridad contaban cada una con cinco o seis puntos de restauración, el más reciente tomado poco antes del ataque, para un total de 35 archivos VMDK. El daño afectó entre el 3 % y el 5 % de cada uno de esos archivos. En una de las tres, el cifrador no había llegado a alcanzar en absoluto los archivos de disco virtual.

Cuando los datos de copia de seguridad por sí solos no cubrían un conjunto de datos, los ingenieros incorporaron las regiones no cifradas de los discos virtuales de producción. Este enfoque resultó eficaz, aunque exigía cautela. Dos de las tres máquinas prioritarias también contaban con archivos de instantáneas, que no tienen una relación uno a uno con los datos que representan. Las estructuras que asociaban los archivos de instantáneas con los datos que representaban se encontraban dentro de las regiones cifradas. Por lo tanto, usar los discos virtuales de producción para completar los vacíos podía introducir datos más antiguos y generar daños difíciles de rastrear posteriormente. Los ingenieros evaluaron el riesgo de cada conjunto de datos en lugar de combinar por defecto.

DriveSavers colaboró con la empresa de respuesta a incidentes y con el cliente para establecer de antemano en qué entorno se importarían los discos. Los datos extraídos a nivel de archivo se devolvieron primero a través de la red, de modo que el cliente pudiera acceder a archivos específicos mientras continuaba el resto del trabajo. A continuación, se entregaron los archivos VMDK completos, listos para su reimportación.