Skip to content

Análisis forense de Volume Shadow Copy Service (VSCS) mediante herramientas Sleuth Kit

Publicado por Sergio Hernando el 30 octubre 2011

Hola,

Disculpas a todos debido a la falta de actualización del blog. Tras casi tres semanas de vacaciones y ocupado en otros asuntos me ha costado encontrar un poco de tiempo libre para contaros algo que pueda ser de interés.

Los lectores del blog posiblemente reconocerán el título, ya que no es la primera vez que hablamos de las copias shadow en sistemas Microsoft Windows. Prácticamente hace un año, publiqué un extenso artículo en el que se podéis encontrar una introducción al análisis forense de Volume Shadow Copy Service (VSCS), que os aconsejo que leáis antes de seguir adelante, tanto para operar con VSCS en línea o para obtener y usar imágenes VSCS. Sobre este último aspecto, echad también un ojo a How to mount and access VSCS y Shadow Timelines And Other VolumeShadowCopy Digital Forensics Techniques with the Sleuthkit on Windows. En este último texto de SANS se dan ejemplos similares a los que trataremos aquí, y en el primer artículo, del maestro Harlan Carvey, se describe bastante bien como montar y acceder a copias shadow.

Desde el punto de vista del análisis forense, y desde la seguridad, las copias shadow son extremadamente interesantes. Por muchos motivos, no sólo por el impacto que tienen, sino también por el escaso tratamiento que se se le da en la literatura de seguridad en plataformas Windows, por no mencionar el grado de conocimiento que los usuarios tienen de estas funcionalidades del sistema operativo. Suelen ser una fuente provechosa de información que no debemos dejar escapar. En este pequeño artículo daremos algunos ejemplos sobre cómo interactuar con VSCS empleando las herramientas Sleuth Kit de Brian Carrier.

Comparación del sistema de ficheros

Aunque no deberían existir cambios, es posible emplear TSK para realizar la comparativa. Emplearemos fsstat. Para el sistema en ejecución:

fsstat \\.\C:

Del mismo modo, se puede obtener la misma información en cualquiera de las copias shadow almacenadas. Recordad que para enumerarlas:

vssadmin list shadows

En mi máquina, en este caso un equipo Windows 7 Home Premium, existen diversas copias shadow, la mayoría son puntos de restauración creados por el sistema en eventos de actualización, aunque algunas copias las he generado yo manualmente con propósitos experimentales. Los detalles de la última copia son:

Contenido de id. de conjunto de instantáneas: {557faa80-ada0-4045-8acb-fb8a7ff3d37f}
Contenía 1 instantáneas en el momento de su creación: 30/10/2011 1:33:17
Id. de instantáneas: {d240053b-b077-4cab-82fd-6c8cfd117d67}
Volumen original: (C:)\\?\Volume{e68a979a-ab2c-11e0-b85f-806e6f6e6963}\
Volumen de instantáneas: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy15
Equipo de origen: shernando-asus
Equipo de servicio: shernando-asus
Proveedor: 'Microsoft Software Shadow Copy provider 1.0'
Tipo: ClientAccessibleWriters
Atributos: Persistente, Accesible para el cliente, Sin liberación automática, Diferencial, Recuperado automáticamente

Con lo que los detalles del sistema de ficheros se obtendrán:

fsstat \\.\HarddiskVolumeShadowCopy15

Siendo los resultados los siguientes:

FILE SYSTEM INFORMATION
--------------------------------------------
File System Type: NTFS
Volume Serial Number: DE18364E18362645
OEM Name: NTFS
Version: Windows XP

METADATA INFORMATION
--------------------------------------------
First Cluster of MFT: 786432
First Cluster of MFT Mirror: 2
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 168448
Root Directory: 5

CONTENT INFORMATION
--------------------------------------------
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 89599998
Total Sector Range: 0 - 716799998

$AttrDef Attribute Values:
$STANDARD_INFORMATION (16) Size: 48-72 Flags: Resident
$ATTRIBUTE_LIST (32) Size: No Limit Flags: Non-resident
$FILE_NAME (48) Size: 68-578 Flags: Resident,Index
$OBJECT_ID (64) Size: 0-256 Flags: Resident
$SECURITY_DESCRIPTOR (80) Size: No Limit Flags: Non-resident
$VOLUME_NAME (96) Size: 2-256 Flags: Resident
$VOLUME_INFORMATION (112) Size: 12-12 Flags: Resident
$DATA (128) Size: No Limit Flags:
$INDEX_ROOT (144) Size: No Limit Flags: Resident
$INDEX_ALLOCATION (160) Size: No Limit Flags: Non-resident
$BITMAP (176) Size: No Limit Flags: Non-resident
$REPARSE_POINT (192) Size: 0-16384 Flags: Non-resident
$EA_INFORMATION (208) Size: 8-8 Flags: Resident
$EA (224) Size: 0-65536 Flags:
$LOGGED_UTILITY_STREAM (256) Size: 0-65536 Flags: Non-resident

Análisis comparativo de ficheros eliminados

Se realizará mediante la herramienta fls. Así, por ejemplo, la enumeración de ficheros eliminados en el entorno en ejecución se obtiene de la siguiente manera:

fls -rpd \\.\C: >>borrados.actuales.txt

Obtenemos la relación de elementos eliminados para la copia número 13:

fls -rpd \\.\HarddiskVolumeShadowCopy13 >> borrados.shadow13.txt

Acto seguido, se comparan ambos ficheros. Debido a que suelen ser largos, la inspección manual completa se hace difícil, así que hay que recurrir a la comparación automática. La manera más sencilla, si estáis trabajando en Windows, es usar las diffutils disponibles en http://gnuwin32.sourceforge.net/packages/diffutils.htm, aunque cualquier otra herramienta de comparación puede servir.

diff.exe borrados.actuales.txt borrados.shadow13.txt >> diff.txt

Llegados a este punto la lista de diferencias puede ser, y de hecho suele ser, bastante grande, ya que dependiendo del formato de salida escogido para fls pueden haber desviaciones no sólo en el nombre de fichero, sino en sus atributos. Centraos de entrada en la actividad del usuario y no en la propia del sistema, que será también parte de la comparativa, ya que la operación del sistema implica, inevitablemente, la adición y eliminación de todo tipo de ficheros. Esta tarea es de aproximación, con lo que la idea es echar un vistazo para localizar actividad que requieran nuestra atención de una manera más específica.

Análisis de elementos eliminados. Cuando no todo es evidente y visible

Tomemos la siguiente línea de ejemplo, procedente de una ejecución fls en la copia shadow número 15 del sistema:

-/r * 168255-128-1: $Recycle.Bin/S-1-5-21-1570750694-33650455-1397092791-1000/$REC6WAH.txt

De la línea anterior se deduce que se trata de una eliminación (denotada por el asterisco) de un fichero regular (valor r) que sigue residiendo en la estructura de metadatos (la segunda r) pero que no tiene una entrada definida en la estructura de nombres de fichero (Signo - en vez de una r), ya que es un fichero eliminado. Casualidades de la vida, $Recycle.Bin nos indica que en esta copia este fichero reside en la papelera de reciclaje.

Anotamos el valor del clúster (168255) e iniciamos nuestro análisis. Empezamos con una ejecución de istat, que arroja los detalles de dicha estructura de metadatos. Marco en negrita información relevante:

istat \\.\HarddiskVolumeShadowCopy15 168255

MFT Entry Header Values:
Entry: 168255 Sequence: 5
$LogFile Sequence Number: 3677255690
Not Allocated File
Links: 1

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 771 ()
Last User Journal Update Sequence Number: 952846744
Created: Sun Oct 30 01:32:03 2011
File Modified: Sun Oct 30 01:09:05 2011
MFT Modified: Sun Oct 30 01:32:18 2011
Accessed: Sun Oct 30 01:32:03 2011

$FILE_NAME Attribute Values:
Flags: Archive
Name: $REC6WAH.txt
Parent MFT Entry: 15909 Sequence: 4
Allocated Size: 64 Actual Size: 62
Created: Sun Oct 30 01:32:03 2011
File Modified: Sun Oct 30 01:09:05 2011
MFT Modified: Sun Oct 30 01:32:03 2011
Accessed: Sun Oct 30 01:32:03 2011

Attributes:
Type: $STANDARD_INFORMATION (16-0) Name: N/A Resident size: 72
Type: $FILE_NAME (48-3) Name: N/A Resident size: 90
Type: $DATA (128-1) Name: N/A Resident size: 62

Podemos obtener la foto completa del clúster 168255 invocando blkstat:

blkstat \\.\HarddiskVolumeShadowCopy15 168255

De lo que obtendremos que el estado es allocated, pero como ya sabíamos, los datos que existen en él son de un fichero borrado. También nos puede interesar verificar los nombres de fichero asociados al clúster, aunque ya los hemos identificado, y para ello usamos ffind:

ffind \\.\HarddiskVolumeShadowCopy15 168262

Lo que arroja:

* /$Recycle.Bin/S-1-5-21-1570750694-33650455-1397092791-1000/$IEC6WAH.txt

Finalmente, accedemos a los contenidos del clúster empleando icat. ¡Sorpresa!

icat \\.\HarddiskVolumeShadowCopy15 168255

shadow forensics

Algunas lecciones aprendidas

  1. Publico poco y a deshoras. Sí, es cierto. Lo reconozco, pero sé que me lo dejáis pasar :D
  2. No todo es evidente en el mundo del análisis forense. Hay cosas que sólo se pueden obtener empleando la intuición y la experiencia previa
  3. Las herramientas Sleuth Kit funcionan perfectamente tanto en Windows como en Linux, y en el caso de Windows, son operables contra el proveedor de VSCS tal y como hemos explicado
  4. Las tecnologías VSCS son muy útiles desde el punto de vista de la usabilidad, ya que permiten crear puntos de restauración que permiten a posteriori recuperar el sistema en caso de un error, o recuperar un fichero eliminado accidentalmente. Desde el punto de vista forense y la seguridad, las tecnologías VSCS tienen un impacto elevado y este impacto debe ser evaluado para cada caso

Un saludo,

Be Sociable, Share!

Categoría/s → Forensics

Sin comentarios

Escribir un comentario

Note: XHTML permitido. Tu email nunca será publicado.

Suscribirse a los comentarios via RSS