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 XPMETADATA 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: 5CONTENT 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 2011Attributes:
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
Algunas lecciones aprendidas
- Publico poco y a deshoras. Sí, es cierto. Lo reconozco, pero sé que me lo dejáis pasar :D
- 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
- 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
- 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,