Investigación con el índice de Windows Search: un caso
Una intrusión ficticia en FIN-WKS-07 analizada con el índice de Windows Search: preparación, credenciales borradas, exfiltración por USB y a la nube.
En resumen. Escenario ficticio, construido sobre el ejemplo sintético que acompaña a la herramienta. En el equipo FIN-WKS-07, el índice de búsqueda de Windows 11 basta por sí solo para esbozar una intrusión de la cuenta svc_backup: un comprimido de herramientas descargado, un binario depositado en C:\ProgramData\Intel, un archivo de credenciales escrito y luego borrado (su texto sobrevive en System.Search.AutoSummary), una hoja de nóminas copiada de un recurso compartido a una unidad extraíble, rclone.exe depositado en Users\Public y una visita a un sitio de almacenamiento en la nube. Los pasos más recientes solo están en Windows.db-wal. Cada hallazgo es una pista que hay que confirmar con otros artefactos, y a continuación se indica con cuáles.
Todo es inventado. La empresa, los equipos, las cuentas, los nombres de archivo, las marcas de tiempo y las credenciales proceden de las bases de demostración generadas para el botón «Probar un ejemplo» del sitio. No se describe ningún incidente ni dato real. Puedes cargar los mismos datos con Probar un ejemplo (Windows 11) en el Windows Search Index Parser y seguir el recorrido.
La situación
El responsable de TI del equipo de finanzas informa de que svc_backup, una cuenta de servicio que nunca debería iniciar sesión de forma interactiva, aparece en la lista de usuarios que han iniciado sesión recientemente en FIN-WKS-07. La máquina se aísla el 14 de septiembre de 2026 por la tarde. Recibes una adquisición de KAPE que incluye el target WindowsIndexSearch. Un compañero se ocupa de los registros de eventos. Empiezas por el índice de búsqueda porque es rápido y es uno de los pocos artefactos que pueden contener el contenido de los archivos.
Paso 1: carga y comprueba que está completo
Al soltar el ZIP de la adquisición se ven Windows.db, Windows.db-wal y Windows-gather.db emparejados desde la misma carpeta. Ningún aviso de WAL o base gather ausentes. Bien: tenemos el estado actual y la comprobación cruzada con gather. Los contadores muestran un índice pequeño: es una demo. Un equipo real mostraría decenas de miles de elementos, y precisamente por eso importa filtrar.
Todas las marcas de tiempo están en UTC (los FILETIME almacenados están en UTC; mantengo la visualización en UTC para el informe).
Paso 2: primero los elementos señalados
Solo señalados, ordenados por fecha de creación (extracto; la marca «Indexado recientemente», presente en la mayoría, se omite para facilitar la lectura):
| Creación (UTC) | Ruta | Marcas |
|---|---|---|
| 09:58:41 | C:\Users\svc_backup | — |
| 10:05:31 | C:\Users\svc_backup\Downloads\tools.zip | carpeta escribible, comprimido |
| 10:07:14 | C:\ProgramData\Intel\m64.exe | carpeta escribible, ejecutable, modificado en el WAL |
| 10:09:48 | C:\ProgramData\Intel\creds.txt | carpeta escribible, fragmento de contenido, fuera de la tabla gather |
| 10:40:12 | E:\exfil\finance_2026\Payroll_2026.xlsx | otra unidad, fragmento de contenido, solo en el WAL |
| 10:45:03 | C:\Users\Public\rclone.exe | carpeta escribible, ejecutable, solo en el WAL |
A eso se suma un registro presente solo en la tabla gather: m64.exe bajo C:\Users\svc_backup\AppData\Local\Temp\7zS4A2.tmp, sin propiedades en el almacén.
Paso 3: lectura de cada elemento
El perfil
C:\Users\svc_backup creado a las 09:58:41. Una carpeta de perfil para una cuenta de servicio en un equipo de trabajo indica que la creó un inicio de sesión interactivo o por RDP. Corroborar: eventos de inicio de sesión (4624 con tipo 10 o 2) en los registros de eventos en torno a las 09:58.
El comprimido de herramientas y la extracción temporal
tools.zip, 4 812 331 bytes, propietario FIN-WKS-07\svc_backup, creado a las 10:05:31, indexado a las 10:05:58. A las 10:06:38, el acceso directo del menú Inicio 7-Zip File Manager.lnk muestra una nueva fecha de acceso. A las 10:06:55, la tabla gather conoce un m64.exe en una carpeta 7zS…tmp bajo el Temp de la cuenta. Sus propiedades han desaparecido del almacén: es el patrón solo en la tabla gather de un archivo temporal que se limpió. Lectura: se abrió el comprimido con 7-Zip y se extrajo m64.exe, primero a una ubicación temporal. Corroborar: Jump Lists de 7-Zip y el diario USN de la carpeta temporal.
El binario depositado
C:\ProgramData\Intel\m64.exe, 1 359 872 bytes, creado a las 10:07:14. ProgramData\Intel es una ruta de preparación clásica «con apariencia legítima»; una carpeta con el nombre de un fabricante de hardware y un ejecutable solitario dentro merece atención. El elemento está modificado en el WAL: la base consolidada tiene una fecha de acceso de las 10:07:14, y el WAL una nueva fecha de acceso de las 10:51:02 y un nuevo gather time de las 10:51:30. Se volvió a tocar 45 minutos después. El índice no prueba la ejecución. Corroborar: Prefetch, Amcache, ShimCache.
El archivo de credenciales borrado
C:\ProgramData\Intel\creds.txt, 214 bytes, creado a las 10:09:48, modificado a las 10:14:02, indexado a las 10:14:30. Está fuera de la tabla gather, y el registro gather de la carpeta Intel muestra una última modificación a las 10:55:04. En el disco, el archivo ha desaparecido. Su fragmento de contenido sigue en el almacén de propiedades:
FIN-SQL01 sa / Winter2026! | FILESRV01 CORP\svc_backup / Bkp#2026-fin | mega: fin-backup
Tres juegos de credenciales: la cuenta sa del servidor SQL, la contraseña de dominio de la propia cuenta de servicio y lo que parece un nombre de cuenta de almacenamiento en la nube. En un informe real lo citaría en un anexo de difusión restringida y lanzaría el cambio de credenciales. Este es el valor descrito en rastros de archivos borrados en el índice de Windows Search: el contenido de un archivo que ya no existe, sin ningún carving. Corroborar: la Papelera de reciclaje (¿se borró desde el Explorador?), el diario USN (registro de borrado de creds.txt hacia las 10:55) y los registros de autenticación de FIN-SQL01 y FILESRV01.
El archivo de nóminas, dos veces
\\FILESRV01\Finance\Payroll\Payroll_2026.xlsx: una ruta de red cuyo propietario es CORP\payroll-admins, 188 406 bytes, última modificación el 12 de septiembre a las 16:02, accedido el 14 de septiembre a las 10:32:15, indexado a las 10:33:01. Fragmento: los encabezados de columna de una tabla de nóminas. El recurso compartido se indexaba en este equipo, así que el índice registra la fecha de acceso tal como la vio.
Después, E:\exfil\finance_2026\Payroll_2026.xlsx: otra unidad, mismo tamaño, misma fecha de modificación (12 de septiembre a las 16:02, conservada por la copia), creado a las 10:40:12, propietario FIN-WKS-07\svc_backup. Solo en el WAL: este registro solo existe en las últimas transacciones, no en la base consolidada. Sin Windows.db-wal no lo verías. Ver análisis forense de Windows.db: SQLite y el WAL. Lectura: copia del archivo de nóminas a una unidad extraíble hacia las 10:40. Corroborar: historial de dispositivos USB en el registro y en los registros de eventos, archivos LNK que apunten a E:\.
rclone y el sitio en la nube
C:\Users\Public\rclone.exe, 58 720 256 bytes, creado a las 10:45:03, accedido a las 10:47:12, solo en el WAL. Rclone es una herramienta de sincronización legítima muy abusada para exfiltrar datos. Un elemento del historial web indexado a las 10:46:52 apunta a https://mega.nz/start, visitado a las 10:46:30, con un SID de usuario que termina en -1013 en su URL iehistory://. Corroborar: asociar el SID a una cuenta con los subárboles SAM / ProfileList, revisar los artefactos del navegador, buscar rclone.conf y los registros de red o de proxy.
Paso 4: la línea temporal
| Hora (UTC) | Evento | Fuente en el índice | Confianza |
|---|---|---|---|
| 09:58:41 | Perfil svc_backup creado | Elemento carpeta | Media: confirmar el inicio de sesión |
| 10:05:31 | tools.zip descargado | Elemento archivo | Media |
| 10:06:38–10:06:55 | 7-Zip usado, m64.exe extraído a temporal | Fecha de acceso del LNK, registro solo en gather | Baja-media |
| 10:07:14 | m64.exe depositado en ProgramData\Intel | Elemento archivo | Media: confirmar la ejecución |
| 10:09–10:14 | creds.txt escrito | Elemento archivo + fragmento | Alta para el contenido a las 10:14 |
| 10:32:15 | Archivo de nóminas accedido en el recurso compartido | Elemento de red | Media |
| 10:40:12 | Nóminas copiadas a E:\exfil\… | Elemento solo en el WAL | Media: confirmar el USB |
| 10:45:03 | rclone.exe depositado | Elemento solo en el WAL | Media |
| 10:46:30 | Sitio de MEGA visitado | Elemento del historial web | Media |
| 10:51:02 | m64.exe tocado de nuevo | Elemento modificado en el WAL | Baja-media |
| ~10:55 | creds.txt borrado | Registro gather ausente, cambio en la carpeta | Media: confirmar con el USN |
Cada línea es una observación del indexador, no por sí misma una ejecución o una acción del usuario. La columna de confianza es lo que defendería ante un revisor antes de corroborar.
Lo que el índice no podía decirnos
- Si
m64.exeorclone.exellegaron a ejecutarse. Hacen falta artefactos de ejecución. - Qué subió rclone. Registros de red, de proxy y de la nube, o
rclone.conf. - Nada fuera de las ubicaciones indexadas. Una herramienta lanzada desde una carpeta no indexada sería invisible aquí.
- Nada posterior a las 10:51. El último gather time del índice marca el límite de su visibilidad.
Conclusiones
- Adquiere el WAL y la base gather: tres de los hallazgos clave dependen de ellos.
- Ordena primero por hora los elementos señalados; abre los detalles después.
- Trata los fragmentos de contenido como prueba del contenido en el momento de la indexación y protégelos como los datos que contienen.
- Redacta cada hallazgo como «el índice registra…» e indica al lado el artefacto que lo corrobora.