← Volver al blog

Probar que un archivo existió cuando ya no está en disco

· 7 min de lectura

Los compromisos forenses giran a menudo en torno a una sola pregunta: ¿estuvo este archivo alguna vez en este ordenador? No "¿está ahí ahora?" (eso es dir). La pregunta más difícil: ¿podemos mostrar que estuvo ayer, la semana pasada, el año pasado? Para volúmenes NTFS la respuesta suele ser sí, y $MFT es la fuente individual más fuerte. Con frecuencia los contenidos del archivo también vuelven.

Esta es la visión práctica de lo que puedes probar solo desde los metadatos MFT, qué corroboración añaden los diarios, y los casos donde las afirmaciones confiadas se desmoronan en revisión.

Lo que sobrevive a una eliminación

Cuando un archivo es eliminado en NTFS, el bit IN_USE en la cabecera del registro se limpia y la entrada de índice del directorio padre se quita. El propio registro permanece, conteniendo:

  • $FILE_NAME con el nombre original del archivo y la referencia al registro MFT del directorio padre.
  • Ocho marcas de tiempo (cuatro en $STANDARD_INFORMATION, cuatro en $FILE_NAME) congeladas en el momento de la eliminación.
  • Tamaños lógico y físico de los datos del archivo.
  • Para archivos pequeños (~700 bytes o menos de $DATA), el contenido completo del archivo almacenado inline en el registro. Mira datos residentes.
  • Para archivos más grandes, la runlist de clusters que contuvieron los datos. Esos clusters pueden o no contener aún los bytes originales.
  • El número de secuencia del registro, que prueba que estás mirando el archivo que vivió en ese slot en ese momento (no a un inquilino posterior).

Un registro MFT eliminado con $FILE_NAME = secret-plan.docx, referencia padre resolviendo a \Users\bob\Documents y SI creado 2024-11-03T14:02:11Z demuestra que un archivo con ese nombre existió en ese directorio ese día. El registro es la evidencia, y la evidencia está firmada por el propio NTFS en el sentido de que el driver del sistema de archivos la escribió.

Lo que hace defendible la evidencia

Tres propiedades hacen que los registros MFT aguanten en una revisión donde alguien intenta romper tu caso:

  1. NTFS los escribe a sí mismo, no el usuario. Los registros no son editables por usuarios a través de las APIs normales de Windows. Un acusado no puede afirmar creíblemente que un único registro fue plantado a menos que argumente que toda la $MFT fue falsificada, lo cual es una barra alta con los cotejos de diario de abajo.
  • Ocho marcas de tiempo se cotejan. La manipulación suele mostrarse. SI cambiado pero FN sin cambiar es la firma de timestomping de manual; mira las cuatro marcas de tiempo de la MFT. SI creado precediendo a FN creado es imposible naturalmente.
  • $UsnJrnl y $LogFile corroboran. Si $MFT dice que el archivo se creó en el momento T, el diario USN debería registrar FILE_CREATE en el mismo momento. Los desacuerdos son ellos mismos evidencia (de falsificación o de error de parser; en cualquier caso, dignos de perseguir).
  • Las instantáneas VSS son independientes. Una instantánea de antes de la eliminación contiene una copia MFT donde el archivo era IN_USE=1. La instantánea fue escrita por VSS en un momento conocido. Dos testigos independientes ($MFT viva + $MFT de la instantánea) mostrando el mismo archivo son mucho más fuertes que cualquiera solo. Mira Volume Shadow Copy y $MFT.

Ese cuarto punto vale la pena detenerse. En casos serios siempre busco instantáneas VSS. Convierten una sola observación en una serie de observaciones, cada una en un punto diferente en el tiempo, y están escritas por un camino de código completamente distinto del de la MFT viva. Difícil de falsificar ambos de manera consistente.

Lo que no puedes probar solo con $MFT

La MFT prueba que el archivo existió en un directorio particular en un momento particular, con el tamaño y las marcas de tiempo particulares en el registro. No prueba:

  • Quién lo creó o accedió. Eso requiere logs de eventos Security (4663 con SACLs, Sysmon Event ID 11/15 o 4688 creación de proceso con línea de comandos si el archivo se nombró en una línea de comandos).
  • Qué programa lo produjo. Prefetch, Amcache y Shimcache ayudan aquí. Sysmon Event ID 1 es el estándar de oro si estaba habilitado.
  • Qué contenía el archivo, para archivos grandes, salvo que recuperes los clusters de datos. Los archivos residentes te dan los bytes; los no residentes requieren que la runlist de clusters siga apuntando a espacio no asignado y no sobrescrito.
  • Si un usuario realmente lo abrió. Las jump lists, los archivos LNK y RecentFileCache son más útiles aquí.
  • Si fue visto por alguien distinto del usuario propietario del directorio. Eso necesita logs de auditoría ACL.

Una respuesta completa suele fusionar la MFT con los artefactos del entorno. La MFT es la piedra angular porque sin ella las demás piezas no tienen donde anclarse. Un hit de Prefetch para secret-tool.exe es interesante; el mismo hit emparejado con un registro MFT mostrando que secret-tool.exe se dejó caer en \Temp\ en el mismo minuto por un proceso cuyo Sysmon Event ID 1 está en la línea temporal es concluyente.

Un flujo que aguanta en revisión

  1. Adquiere $MFT, $UsnJrnl:$J, $LogFile, todas las instantáneas VSS. Hashea todo (SHA-256). Documenta la hora de adquisición.
  2. Parsea la MFT. Encuentra el registro para el archivo en cuestión, vivo o eliminado. Saca el número de secuencia, la referencia padre, las ocho marcas de tiempo, los datos residentes $DATA si los hay, y la runlist de clusters si no.
  3. Resuelve la referencia padre siguiendo el registro MFT del padre. Repite hasta llegar al registro 5 (la raíz). La cadena resultante es la ruta del directorio. Cótejala contra cualquier ruta que tengas de logs o testigos.
  4. Cruza con el diario USN. Para el mismo par registro/secuencia, lista cada entrada USN. FILE_CREATE te da la creación original; FILE_DELETE te da la eliminación. Las razones intermedias son la historia del archivo.
  5. Compara contra las MFTs de las instantáneas VSS. La copia de cada instantánea del mismo registro te da un checkpoint. Si tres instantáneas muestran el registro IN_USE=1 con marcas de tiempo consistentes y la MFT viva muestra IN_USE=0, tienes cuatro testigos independientes acordando la existencia del archivo y un testigo de su eliminación.
  6. Documenta las imposibilidades que descartaste. Divergencia SI/FN comprobada. Números de secuencia consistentes. Marcas de tiempo de instantánea coherentes. La narrativa de la defensa tiene que explicar todas estas para socavar tu conclusión.

El último paso es lo que separa un hallazgo de un argumento. Enumerar lo que comprobaste y lo que descartaste hace visible la cadena de razonamiento.

Casos límite que muerden

Hard links. Un archivo con múltiples hard links vive a través de múltiples atributos $FILE_NAME. Eliminar un link solo quita ese nombre; el archivo permanece. Confirma que la eliminación que rastreas realmente corresponde al archivo desapareciendo, no a un único nombre siendo quitado.

Archivo renombrado antes de la eliminación. Algunos droppers renombran su archivo de staging a un nombre benigno justo antes de la eliminación, esperando que el $FILE_NAME superviviente parezca inocuo. El diario USN preserva el par RENAME_OLD_NAME / RENAME_NEW_NAME. Sácalo.

Slot de registro reutilizado. El slot de un archivo eliminado ha sido reclamado por un archivo nuevo. El registro MFT actual es el archivo nuevo en secuencia N; el diario referencia al archivo antiguo en secuencia N-1. Usa el número de secuencia para desambiguar. Las referencias que apuntan a una secuencia distinta de la actual apuntan a un inquilino anterior.

El archivo nunca existió y alguien miente. Menos común, pero vale la pena saberlo. La falsificación de metadatos puros es difícil de hacer de manera consistente a través de MFT, USN y VSS, pero un operador determinado con acceso de administrador tiene herramientas. Busca inconsistencias entre artefactos que deberían coincidir.

Lecturas adicionales

Artículos relacionados

Recursos externos