La pregunta más común que reciben los analistas forenses de partes no técnicas es alguna variante de «¿puedes probar que ese archivo existió?». Cuando el archivo ya no está en el disco, la papelera fue vaciada y ha pasado tiempo suficiente para que la entrada $MFT se haya reciclado, la respuesta suele depender de lo que el journal USN aún recuerde.
Este artículo recorre lo que el journal preserva sobre archivos eliminados, cómo extraer esa evidencia y las situaciones en las que el journal es tu último testigo.
Qué guarda el journal después del borrado
Cuando un archivo se elimina en NTFS suceden varias cosas:
- La entrada
$FILE_NAMEen el directorio padre se desliga. - La entrada MFT se marca como libre — pero no se pone a cero.
- El journal USN recibe un registro
FileDelete | Closeque nombra el archivo, su referencia padre, su entrada MFT y la marca temporal.
El registro del journal es el más resistente de los tres. La entrada de directorio desaparece en cuanto el padre se reescribe; la entrada MFT puede ser reutilizada en cuanto se crea un nuevo archivo; el registro del journal vive en un buffer circular que solo se da la vuelta tras días o semanas de actividad.
Eso significa que, para archivos eliminados hace días, el journal te suele dar:
- El nombre de archivo (solo la hoja, no la ruta completa).
- La referencia MFT del directorio padre — combinada con un
$MFTparseado, da la ruta. - La marca temporal de la eliminación en UTC.
- El número de entrada MFT que ocupaba el archivo (útil para cruzar con artefactos carvados).
- Un rastro de ciclo de vida: los registros
FileCreate,DataExtend,BasicInfoChangeanteriores al borrado dicen cuándo se creó el archivo, cómo se escribió y si sus timestamps fueron modificados.
Un workflow mínimo de recuperación
Con un journal parseado (el parser de esta página o usnrs sirven; ver la guía de extracción para obtener $J y $MFT):
- Filtrar por
FileDeletepara sacar cada eliminación en la ventana. Ordenar por timestamp. - Para cada eliminación de interés, agrupar por
FileReferenceNumberpara ver el historial completo del archivo — creación, escrituras, pares de rename, cambios de atributos y al final el borrado. - Resolver la ruta padre vía el
$MFT. Con ambos archivos provistos, nuestro parser lo hace automáticamente. - Cruzar con
$LogFilesi la eliminación es muy reciente — puede aún contener la imagen «antes» de la entrada de directorio, dándote un segundo testigo independiente.
La combinación «tengo una referencia MFT, un nombre, un padre, una marca de creación y una de eliminación» suele bastar para satisfacer una retención legal o anclar una investigación más profunda.
Cuando no se puede resolver la ruta padre
A veces, en el momento de mirar, la propia entrada MFT padre ya ha sido reciclada — sobre todo en hosts con mucha actividad. En ese caso el journal te da el nombre y la referencia padre, pero $MFT ya no sabe a qué carpeta correspondía ese número.
Tres cosas suelen ayudar:
- Registros
RenameNewNameanteriores sobre la referencia padre — pueden traer un padre resoluble en el momento del rename. - Entradas de índice de
$LogFile— no documentadas pero cubiertas porlibfsntfs. - Archivos hermanos bajo la misma referencia padre — agrupar todos los registros del journal por padre. Si uno de los hermanos fue renombrado hacia un directorio cuya entrada MFT sigue válida, puedes pivotar por él.
Por eso los reportes provisionales de esta herramienta dicen «filename: notes.docx» sin ruta: preferimos no inventar una ruta que no podemos verificar.
«Borrado seguro» no significa desaparecido
Algunas herramientas de destrucción de archivos (CCleaner, Eraser, BleachBit) sobrescriben el contenido y luego eliminan. Dejan los mismos registros de journal que un borrado normal más los registros de sobrescritura. El journal por tanto hace ruidosa la «eliminación segura», no silenciosa:
- Múltiples
DataOverwrite | Closeen el archivo antes de suFileDelete | Closeindican sobrescritura intencional. - Un
FileCreatey unFileDeletedel mismo archivo en segundos, con sobrescrituras en medio, es el patrón canónico. - Si el shredder además limpió el espacio libre escribiendo archivos temporales, esos temporales tienen sus propias secuencias create/extend/overwrite/delete — un enjambre de registros alrededor del momento de la destrucción.
La técnica de MITRE ATT&CK que mapea aquí es T1485 Data Destruction y T1070.004 File Deletion.
¿Y el contenido del archivo?
El journal USN nunca lleva contenido — solo metadatos de operaciones. Si necesitas recuperar bytes, el journal te apunta a:
- El número de entrada MFT del archivo eliminado. Si la entrada no se reutilizó, el MFT aún guarda los data runs y el contenido puede recuperarse vía
icatde The Sleuth Kit o X-Ways. - Las imágenes «antes» de
$LogFilepara eliminaciones muy recientes. - Las Volume Shadow Copies (VSS) si existen — el archivo eliminado puede vivir en un snapshot previo.
- Almacenes específicos de aplicación — papelera de OneDrive, carpeta «Autoguardado» de Office, cachés de navegador.
El papel del journal aquí es decir que un archivo existió y cuándo fue eliminado — el resto de la recuperación es aguas abajo.
Límites prácticos
- El journal tiene una ventana temporal. Archivos eliminados antes de que el buffer circular se haya dado la vuelta sobre el registro más viejo que tienes simplemente ya no están en este artefacto. Tira
$LogFiley shadow copies como complemento. - Algunas operaciones no tocan el journal: cambios de cifrado a nivel de sistema de archivos, escrituras en regiones sparse que solo tocan el mapa de asignación, y manipulaciones de reparse points NTFS pueden no producir registros
DataExtend/DataOverwrite. - Un
FileDeletesinFileCreatecorrespondiente en la ventana significa que el archivo se creó antes del registro más viejo del journal — su ciclo de vida es parcial, pero la marca de eliminación puede igual servirte de ancla.
Para contexto más amplio de artefactos, ver el póster SANS Windows Forensic Analysis y la referencia change journals de Microsoft Learn.