Análisis forense del índice de Windows Search: guía
Qué registra el índice de Windows Search, dónde están Windows.edb y Windows.db, qué sobrevive al borrado de un archivo y cómo analizar ambos formatos en DFIR.
En resumen. Windows Search mantiene una base de datos de todo lo que indexa: ruta completa, tamaño, propietario, marcas de tiempo MAC, la hora de indexación y, en documentos de tipo texto, un fragmento del contenido. En Windows 10 y versiones anteriores esa base es Windows.edb (ESE). En Windows 11 son Windows.db y Windows-gather.db (SQLite, con registros WAL). Ambas están en C:\ProgramData\Microsoft\Search\Data\Applications\Windows\. El índice no se purga en tiempo real, así que con frecuencia conserva la ruta, los metadatos y el texto de archivos borrados del disco. Es uno de los pocos artefactos que pueden darte el contenido de un archivo eliminado sin carving. Trátalo como prueba de que un archivo existió y de que el indexador lo vio, no como prueba de que alguien lo abrió.
He visto este artefacto ignorado en más informes de los que puedo contar, normalmente porque la suite del analista no lo procesaba o porque Windows.edb sonaba a buzón de Exchange. Una lástima: en un equipo de trabajo típico es un inventario estructurado y con marcas de tiempo de los documentos del usuario, del menú Inicio y, según la versión de Windows, del historial web y de la actividad.
Qué es el índice de Windows Search
El servicio Windows Search (WSearch, proceso SearchIndexer.exe) recorre las ubicaciones configuradas, aplica los controladores de propiedades y los filtros a cada archivo y guarda el resultado para que el menú Inicio y el Explorador de archivos respondan al instante. La guía de rendimiento de Windows Search de Microsoft sitúa el equipo de un usuario típico por debajo de 30 000 elementos indexados y fija un límite práctico de alrededor de un millón.
Un único índice sirve a toda la máquina. Los elementos de todos los perfiles de usuario que estén dentro de una ubicación indexada acaban en la misma base, de ahí la importancia de la propiedad de propietario (System.FileOwner).
Lo que se indexa depende de la configuración:
| Configuración | Efecto sobre las evidencias |
|---|---|
| Modo clásico | Microsoft lo describe como la indexación de Documentos, Imágenes, Música y el escritorio. En la práctica, la lista de Opciones de indización suele incluir la carpeta Users y el menú Inicio. |
| Modo mejorado | Todo el equipo, incluidas carpetas fuera del perfil. Más cobertura, índice más grande. |
| Ubicaciones añadidas | Cualquier carpeta, unidad o recurso compartido añadido por un administrador o un usuario. Las unidades extraíbles aparecen con su propia letra. |
| «Solo propiedades» o «propiedades y contenido», por tipo de archivo | Determina si obtienes un fragmento de contenido para esa extensión. |
Comprueba siempre qué se indexaba en tu equipo antes de argumentar a partir de una ausencia. Las tablas gather (ver más abajo) enumeran los ámbitos rastreados, y la herramienta muestra el árbol de carpetas que reconstruye a partir de ellas.
Dónde están las bases de datos
| Versión de Windows | Archivos en C:\ProgramData\Microsoft\Search\Data\Applications\Windows\ | Formato |
|---|---|---|
| Windows Vista a Windows 10 | Windows.edb, MSS*.log, MSS.chk, *.jrs, tmp.edb | ESE (JET Blue) con registros de transacciones |
| Windows 11 | Windows.db + Windows.db-wal, Windows-gather.db + -wal, Windows-usn.db y otros | SQLite en modo WAL |
El propio artículo de solución de problemas de Microsoft cita Windows.edb para Windows 10 y Windows.db para Windows 11 en esa misma carpeta. Las fuentes no coinciden en la versión exacta de Windows 11 que hizo el cambio, así que mi regla es simple: mira la carpeta. El procedimiento completo de adquisición, con archivos bloqueados e instantáneas de volumen, está en dónde se guardan Windows.edb y Windows.db y cómo adquirirlos.
Cómo se organizan los datos
Ambos formatos guardan dos tipos de registros.
El almacén de propiedades contiene un registro lógico por elemento indexado, identificado por un WorkId. En Windows 10 es SystemIndex_PropertyStore, una tabla ESE muy ancha con cientos de columnas con nombres como 4447-System_ItemPathDisplay. En Windows 11 es SystemIndex_1_PropertyStore, una tabla SQLite estrecha con una fila por (WorkId, ColumnId, Value), y SystemIndex_1_PropertyStore_Metadata asigna cada ColumnId a un nombre de propiedad. La comparación de formatos cubre ambas estructuras.
Las tablas gather (SystemIndex_Gthr y SystemIndex_GthrPth) son la contabilidad del rastreador: qué documentos conoce, en qué ámbito (carpeta) y con qué fecha de última modificación. En Windows 11 están en Windows-gather.db. El DocumentID de la tabla gather coincide con el WorkId del almacén de propiedades.
Esa separación es útil. Un elemento que sigue en el almacén de propiedades pero falta en la tabla gather es candidato a «borrado después de indexarse». El Windows Search Index Parser señala exactamente ese caso.
Qué puedes obtener
| Evidencia | Propiedad o tabla | Por qué importa |
|---|---|---|
| Ruta completa de un archivo o carpeta | System.ItemPathDisplay | Existencia de un archivo en una ubicación, incluso mucho después de desaparecer |
| Tamaño, propietario, nombre del equipo | System.Size, System.FileOwner, System.ComputerName | Atribución e identificación |
| Creación / modificación / acceso | System.DateCreated, System.DateModified, System.DateAccessed | Marcas de tiempo del sistema de archivos vistas al indexar |
| Cuándo lo procesó el indexador | System.Search.GatherTime | Una marca de tiempo independiente en la que los atacantes rara vez piensan |
| Contenido textual | System.Search.AutoSummary | Parte de un documento, script o nota, incluso tras el borrado |
Historial de navegación (IE / Edge antiguo; System.Link.TargetUrl en Windows 11) | Propiedades de URL | Actividad web cuando las bases del navegador han desaparecido |
| Elementos del historial de actividad | System.ItemType = ActivityHistoryItem | Uso de aplicaciones y archivos vinculado al SID de un usuario |
Lo relativo a URL y ActivityHistory procede de la investigación de Stroz Friedberg de 2023, publicada por Phalgun Kulkarni y Julia Paluch como Windows Search Index: The Forensic Artifact You've Been Searching For. Es la mejor descripción pública del contenido de la estructura de Windows 11. Cada propiedad se explica en detalle en las propiedades del índice de Windows Search explicadas.
El ángulo de los archivos borrados
La razón por la que este artefacto merece un sitio en cada triaje de Windows es que el índice va por detrás del disco. Cuando se borra un archivo, el indexador recibe la notificación y acaba eliminando el registro, pero «acaba» puede tardar mucho en una máquina ocupada o apagada. En Windows 11, la eliminación llega primero al registro WAL. Chivers y Hargreaves ya demostraron en 2011 (Forensic data recovery from the Windows Search Database, Digital Investigation) que los registros de archivos no disponibles persisten y que se pueden recuperar registros borrados del espacio no utilizado de la base.
En la práctica encontrarás tres situaciones, tratadas en qué guarda el índice de los archivos borrados:
- El registro sigue activo en el almacén de propiedades. Cualquier analizador lo muestra.
- El registro ha desaparecido de la base consolidada (checkpoint) pero sigue en el WAL (Windows 11), o al revés.
- El registro se eliminó de la base y solo sobrevive en páginas libres. Eso requiere carving.
Un flujo de trabajo que se sostiene
- Adquiere la carpeta entera, no solo la base principal: archivos WAL, base gather, registros ESE. Usa el target de KAPE
WindowsIndexSearch, Velociraptor o una imagen de disco. - Comprueba el estado. En ESE, un cierre incorrecto (dirty shutdown) significa que hay cambios recientes todavía en los registros. Consulta cómo reparar un Windows.edb en dirty shutdown con esentutl. En SQLite, mantén juntos
Windows.dbyWindows.db-wal. - Analiza y pivota. Abre la carpeta en el analizador en el navegador (ver la guía paso a paso) o en la herramienta que prefieras. Exporta a CSV para tu línea temporal.
- Filtra lo que importa: rutas escribibles por el usuario, ejecutables, archivos comprimidos, otras letras de unidad, rutas de red, fragmentos de contenido, elementos ausentes de la tabla gather.
- Corrobora. Una ruta en el índice es una pista. Relaciónala con archivos LNK, Jump Lists, el diario USN, la Papelera de reciclaje o Amcache antes de escribir «el usuario abrió».
Un caso completo (ficticio) está en investigar una intrusión con el índice de Windows Search.
Límites que debes indicar en el informe
- Alcance. Solo se cubren las ubicaciones indexadas. Carpetas excluidas, unidades no indexadas y tipos de archivo configurados como «solo propiedades» dejan huecos.
- La configuración puede cambiar. El servicio puede deshabilitarse y el índice reconstruirse o borrarse. Ver antiforense contra el índice.
- Las marcas de tiempo son copias. Las fechas MAC son las que el sistema de archivos indicaba al indexar; los cambios posteriores solo se ven si el elemento se reindexó.
- Esquema no documentado. Microsoft documenta las propiedades, no la estructura de la base. Todo lo relativo a las tablas procede de investigación pública e ingeniería inversa.
- Madurez de las herramientas. Los analizadores discrepan en casos límite. Contrasta los hallazgos clave con una segunda herramienta; la comparativa de analizadores enumera las opciones. En el caso concreto del Windows Search Index Parser: su lector ESE (Windows.edb) solo se ha validado de momento con bases sintéticas, su decodificación de Windows 11 sigue la investigación pública porque Microsoft no documenta el esquema, y todavía no recupera registros borrados de las páginas libres.
Preguntas frecuentes
¿El índice de Windows Search está activado por defecto?
Sí. El servicio Windows Search (WSearch) se inicia automáticamente en las ediciones cliente de Windows e indexa las ubicaciones predeterminadas, salvo que alguien haya deshabilitado el servicio o excluido carpetas.
¿El índice demuestra que un usuario abrió un archivo?
No. Demuestra que el indexador vio el archivo en una ruta concreta con unos metadatos concretos. La apertura y la ejecución requieren otros artefactos, como archivos LNK, Jump Lists, Prefetch o los elementos ActivityHistory que el propio índice puede contener.
¿Puedo fiarme de las marcas de tiempo?
Las fechas de creación, modificación y acceso son copias de los valores del sistema de archivos en el momento de la indexación. El gather time procede del reloj del propio indexador. Todas son FILETIME en UTC.
Consulta también la definición de FILETIME.
Lecturas recomendadas
- Microsoft Learn: Troubleshoot Windows Search performance.
- Kulkarni y Paluch (Stroz Friedberg): investigación sobre el índice de Windows Search y SIDR.
- Kaspersky Securelist: artefactos forenses en Windows 11.
- Chivers y Hargreaves (2011): Forensic data recovery from the Windows Search Database.