Índice de Windows Search: rastros de archivos borrados

En resumen. El índice de Windows Search no elimina un registro en cuanto desaparece un archivo. Puedes encontrar archivos borrados en tres lugares: registros activos que siguen en el almacén de propiedades (ruta, tamaño, propietario, marcas de tiempo, hora de indexación y a menudo un fragmento de contenido), diferencias del WAL en Windows 11 (un registro presente en un estado de Windows.db y no en el otro) y espacio libre dentro de la base (entradas ESE «defunct», páginas de la freelist de SQLite), que requiere carving. Un elemento del almacén de propiedades sin registro gather correspondiente es una pista sólida de «¿borrado?». El fragmento de contenido de System.Search.AutoSummary es el premio: el texto de un archivo que ya no existe, sin hacer carving del disco.

Por qué persisten los archivos borrados

El indexador se entera de un borrado a través del seguimiento de cambios del sistema de archivos, encola el trabajo y acaba eliminando el elemento. Varias cosas lo retrasan:

• La máquina se apagó, hibernó o se incautó justo después del borrado.
• El indexador estaba en pausa, ocupado, con batería o retirándose por la actividad del usuario. La guía de solución de problemas de Microsoft enumera estos estados.
• El elemento estaba en una unidad que ya no está conectada: un USB desenchufado o un recurso compartido inaccesible. Chivers y Hargreaves señalaron en su artículo de 2011 que los registros de archivos no disponibles persisten.
• En Windows 11, la eliminación es una transacción confirmada en Windows.db-wal hasta que un checkpoint la escribe en Windows.db. El trabajo de Stroz Friedberg señala que el registro de un archivo borrado sigue disponible en la base principal hasta que los cambios del WAL se vuelcan en ella.

Nada de esto está garantizado. Es una carrera que a veces ganas.

Nivel 1: registros activos de archivos que ya no existen

El caso más sencillo. El archivo ha desaparecido del disco, pero su registro sigue siendo una fila normal del almacén de propiedades. Cualquier analizador lo muestra, con todo el conjunto de propiedades:

¿Cómo sabes que el archivo está borrado? El índice no lo dice. Lo comparas con el sistema de archivos de tu imagen (MFT, listado de directorios). O, más rápido, miras las tablas gather.

La comprobación cruzada con la tabla gather

El almacén de propiedades y las tablas gather (SystemIndex_Gthr) son dos vistas de los mismos elementos, unidas por WorkId = DocumentID. Cuando el rastreador procesa un borrado, las dos no siempre desaparecen a la vez. El Windows Search Index Parser las compara:

• Fuera de la tabla gather (¿eliminado?): el almacén de propiedades aún tiene el elemento y la tabla gather ya no. Buen candidato a «borrado después de indexarse».
• Solo en la tabla gather: el rastreador todavía lista el documento pero sus propiedades han desaparecido. Habitual con archivos temporales, como un comprimido extraído en una carpeta temporal y luego limpiado.

Ambas marcas son heurísticas. Confírmalas con el sistema de archivos, el diario USN (motivo FILE_DELETE para el mismo nombre) o la Papelera de reciclaje (los archivos $I contienen la ruta original y la hora de borrado).

Nivel 2: el registro WAL de Windows 11

Windows.db-wal contiene páginas confirmadas más recientes que las páginas correspondientes de Windows.db. Eso te da dos estados del índice:

• La base sola: el estado en el último checkpoint.
• La base más el WAL: el estado actual.

Un elemento presente en el primero y ausente en el segundo fue eliminado por una transacción reciente. Un elemento presente solo en el segundo se añadió recientemente: es lo que el analizador marca como solo en el WAL. Un elemento cuyas propiedades difieren se reindexó recientemente (modificado en el WAL): por ejemplo, un archivo sobrescrito o ejecutado de nuevo. El análisis a fondo de SQLite y el WAL explica cómo funcionan las tramas y los checkpoints, y por qué el WAL puede incluso contener varias versiones antiguas de la misma página.

Consecuencia práctica: no analices nunca un índice de Windows 11 sin su WAL, y no dejes nunca que una herramienta abra el original en modo lectura-escritura. Un cliente SQLite normal puede consolidar al cerrar, fusionar el WAL y destruir el estado «anterior».

Nivel 3: registros en el espacio libre

Cuando la base sí elimina un registro, los bytes no se borran de inmediato.

• ESE: la entrada eliminada se marca como «defunct» en su página y se limpia más tarde. Las páginas que quedan vacías vuelven al espacio libre. La documentación del formato de libesedb describe las etiquetas de página implicadas.
• SQLite: las celdas eliminadas pasan a freeblocks dentro de la página, las páginas vaciadas van a la freelist, y pueden quedar versiones antiguas de páginas en tramas WAL sobrescritas lógicamente pero no físicamente.

Recuperarlos requiere una herramienta de carving que entienda el formato. Chivers y Hargreaves construyeron una (wdsCarve) para su investigación. WinSearchDBAnalyzer recupera registros borrados de Windows.edb. El Windows Search Index Parser todavía no hace carving: en ESE cuenta las entradas «defunct» que ve e indica el número en un aviso, para que sepas que hay algo que recuperar con otra herramienta.

Fragmentos de contenido: el motivo para prestar atención

System.Search.AutoSummary lo describe Microsoft como un resumen automático del texto completo de un documento. En la práctica es un extracto del principio del texto. La investigación de Stroz Friedberg informa de hasta los primeros 1024 bytes en Windows 11 y enumera los tipos de archivo donde lo observaron: documentos (.txt, .docx, .xlsx, .pdf, .one, .eml), archivos web y de configuración (.html, .xml, .ini, .reg, .sql, .asp) y scripts (.bat, .cmd, .vbs, .js).

Lo que busco en los fragmentos:

• Credenciales y notas que un atacante guardó en el equipo y luego borró.
• Scripts: las primeras líneas de un .bat o un .vbs muestran la intención aunque el archivo haya desaparecido.
• Notas de rescate y sus datos de contacto.
• Títulos y primeras líneas de documentos que prueban que un documento sensible estuvo en una carpeta de preparación.

Dos precauciones:

1. El fragmento refleja el contenido en el momento de la indexación. Si el archivo se modificó después y no se reindexó, el fragmento está desfasado. Compara System.DateModified con la hora de indexación.
2. La indexación del contenido depende de la configuración. Si un tipo de archivo está configurado como «solo propiedades» en Opciones de indización, o la ubicación no se indexa, no hay fragmento. Microsoft documenta ambas opciones. La ausencia de fragmento no demuestra nada.

Un ejemplo breve

En el caso ficticio que acompaña a la herramienta como ejemplo, el intruso borra un archivo C:\ProgramData\Intel\creds.txt. El archivo ha desaparecido y la tabla gather ya no lo lista, pero el almacén de propiedades conserva su ruta, su propietario (FIN-WKS-07\svc_backup), su tamaño (214 bytes), sus marcas de tiempo y un fragmento con las credenciales que el atacante había reunido. El recorrido completo está en investigar una intrusión con el índice de Windows Search.

Cómo redactarlo en el informe

• Escribe «el índice de Windows Search contiene un registro para la ruta X, indexado a las T». No escribas «el archivo existió hasta T».
• Cita el fragmento como «contenido indexado», con la salvedad de que refleja el archivo en el momento de la indexación.
• Indica si el WAL y la base gather estaban disponibles y si una base ESE estaba en estado dirty.
• Si te apoyaste en las marcas de la herramienta, di que son heurísticas y cómo las confirmaste.

Preguntas frecuentes

¿Cuánto tiempo permanece un archivo borrado en el índice de Windows Search?

No hay un plazo fijo. Depende de cuándo procese el indexador el borrado, de si la máquina estaba encendida y del mantenimiento de la base. Trata cada registro superviviente como un golpe de suerte y documenta cuándo se adquirió el índice.

¿Puede el índice darme el contenido completo de un documento borrado?

Normalmente no. System.Search.AutoSummary contiene un extracto, no el archivo. La investigación de Stroz Friedberg describe hasta los primeros 1024 bytes en Windows 11. A menudo basta para unas credenciales, una nota de rescate o las primeras líneas de un script.

Artículos relacionados

• Las propiedades del índice de Windows Search explicadas
• Análisis forense de Windows.db: SQLite y el WAL
• Antiforense contra el índice de Windows Search