Forense de bases ESE: fundamentos para investigadores

En resumen. ESE, también llamado JET Blue, es el motor de base de datos embebido detrás de Windows.edb, SRUDB.dat, WebCacheV01.dat, el ntds.dit de Active Directory y Exchange. Un archivo ESE es una cabecera (con su copia de respaldo) seguida de páginas de tamaño fijo organizadas en árboles B+. El catálogo MSysObjects describe cada tabla y cada columna. Las filas mezclan columnas fijas, variables y tagged (dispersas). Los valores grandes viven en un árbol de valores largos separado. El texto suele estar comprimido. Los cambios pasan primero por registros de transacciones, y por eso una copia en caliente está en estado «dirty». Las filas borradas se marcan como «defunct» y se limpian más tarde, y ese intervalo es donde el carving encuentra evidencias. Saber esto te ayuda a juzgar la salida de cualquier analizador ESE, incluido este.

Por qué debería importarle a un analista forense

No necesitas escribir un analizador ESE. Sí necesitas saber lo suficiente para responder preguntas como: ¿por qué la herramienta A muestra 41 000 filas y la herramienta B 40 212? ¿Por qué esta columna aparece vacía en un visor y no en otro? ¿Se puede informar sobre una base en estado dirty? Las respuestas están en el formato.

Microsoft describe ESE como un motor ISAM (método de acceso secuencial indexado) con transacciones, recuperación ante fallos mediante un registro de escritura anticipada y soporte para tablas anchas con muchas columnas dispersas y multivalor. Esto último es justo lo que necesita Windows Search: cientos de propiedades posibles y un puñado rellenado por elemento. Microsoft publicó el código fuente del motor con licencia MIT en 2021. La referencia más útil para fines forenses sigue siendo la documentación del formato de libesedb de Joachim Metz.

Otras bases ESE que puedes encontrarte en el mismo caso:

La cabecera del archivo

La primera página del archivo es la cabecera. La sigue una segunda copia, la cabecera de respaldo (shadow header). Los campos que importan:

El estado de la base es lo primero que hay que comprobar. esentutl /mh Windows.edb lo muestra (State: Dirty Shutdown), como se ve en la entrada archivada de Microsoft sobre esentutl y VSS. Un dirty shutdown significa que puede haber cambios confirmados que solo estén en los registros. Ver reparar un Windows.edb en dirty shutdown.

Si la cabecera principal está dañada, un analizador puede recurrir a la copia de respaldo. El Windows Search Index Parser lo hace y lo indica en sus avisos.

Páginas y árboles B+

Tras las dos páginas de cabecera, el archivo es una matriz de páginas del tamaño declarado. Cada página tiene una cabecera (40 bytes; 80 bytes en la estructura extendida que usan las páginas de 16 y 32 KiB desde Windows 7) y una matriz de etiquetas (tags) al final de la página que apuntan a las entradas que contiene.

Las páginas forman árboles B+. Los datos de una tabla son un árbol; cada índice es otro; los valores largos, un tercero. Las páginas rama apuntan a páginas hijas; las páginas hoja contienen los registros. Las entradas de una página pueden compartir un prefijo de clave común con la primera entrada de la página, un pequeño truco de compresión que los analizadores deben deshacer para reconstruir las claves.

Dos detalles a nivel de página importan en forense:

• Entradas «defunct». Un registro borrado se marca primero en su etiqueta y se deja en su sitio. Desaparece cuando la página se limpia o se reorganiza.
• Espacio libre. El espacio liberado por borrados y fusiones de páginas se reutiliza más tarde, no se borra de inmediato. Registros antiguos pueden sobrevivir ahí.

El catálogo: MSysObjects

MSysObjects es una tabla como cualquier otra, en una ubicación conocida (su raíz es la página 4). Enumera cada tabla, columna, índice y árbol de valores largos, con sus identificadores, tipos, páginas de códigos y páginas raíz. Un analizador lee primero el catálogo y después recorre el árbol de cada tabla. Entre las tablas de Windows Search que verás en él están SystemIndex_PropertyStore, SystemIndex_Gthr y SystemIndex_GthrPth.

Registros: columnas fijas, variables y tagged

Un registro ESE tiene tres partes:

SystemIndex_PropertyStore depende mucho de las columnas tagged: el elemento tiene un WorkID y solo las propiedades que realmente se rellenaron. Las columnas tagged multivalor contienen listas, como System.Kind = program; executable. Un analizador que ignora los multivalores pierde datos en silencio.

Valores largos

Un valor demasiado grande para el registro, como un fragmento de contenido largo o una propiedad binaria grande, se guarda en el árbol de valores largos de la tabla, y el registro solo conserva una referencia (un identificador de valor largo de 4 u 8 bytes según la versión del motor). Un analizador que no sigue esas referencias muestra la propiedad vacía o como un blob binario corto. Cuando dos herramientas no coinciden en si existe un fragmento, este es el primer sospechoso.

Compresión

ESE puede comprimir los datos de las columnas. La documentación de libesedb describe:

• Compresión de 7 bits para texto ASCII o Unicode corto: los caracteres se empaquetan en 7 bits.
• XPRESS (LZ77) para valores más grandes, identificada por un byte inicial.
• Esquemas más nuevos en versiones recientes del motor, que no todos los analizadores implementan.

Un analizador que no admite un esquema concreto muestra basura o nada. El Windows Search Index Parser admite 7 bits y XPRESS (LZ77 simple) e indica los valores que no pudo decodificar en lugar de ocultarlos. XPRESS9 / XPRESS10 / LZ4 aún no están soportados.

Registros de transacciones y checkpoint

ESE escribe los cambios en archivos de registro secuenciales (en Windows Search: MSS.log, MSS00001.log…), y MSS.chk anota hasta dónde se han aplicado. El archivo de base se actualiza más tarde. Consecuencias:

• Una copia de una base en funcionamiento solo contiene lo que se volcó a disco. El resto está en los registros.
• esentutl /r MSS reproduce los registros en la base (recuperación suave, soft recovery). Siempre sobre una copia.
• Los propios registros son huellas de cambios recientes. Existen herramientas específicas para analizarlos, algo que queda fuera de lo que hacen la mayoría de los analizadores.

Dónde se esconden los registros borrados de Windows Search en ESE

El Windows Search Index Parser cuenta de momento las entradas «defunct» de las tablas que recorre e indica su número, sin recuperarlas. Más sobre lo que sobrevive en rastros de archivos borrados en el índice de Windows Search.

Una nota sobre la validación

ESE es amplio y los detalles cambian entre versiones del motor. El lector ESE del Windows Search Index Parser sigue la documentación de libesedb y el código fuente de Microsoft, y se prueba contra un escritor ESE sintético. Eso demuestra coherencia interna, no exactitud en cada Windows.edb real. Hasta ahora no se ha validado con bases reales, y la interfaz lo dice. Cuando un hallazgo importa, compáralo con esedbexport, ESEDatabaseView o SIDR, como se explica en la comparativa de analizadores.

Artículos relacionados

• Windows.edb frente a Windows.db
• Reparar un Windows.edb en dirty shutdown con esentutl
• Análisis forense del índice de Windows Search: guía completa