La única frase más útil que puedo ofrecer a un examinador nuevo sobre NTFS: la eliminación no es borrado. Es un cambio de bandera y una actualización de índice. El registro MFT del archivo se queda donde está. Los clusters de datos se marcan como libres en $Bitmap. Nada se sobrescribe hasta que algo más pida ese espacio.
La gente lo sabe en abstracto. El error que sigo viéndoles cometer es asumir que la ventana de supervivencia es generosa en cualquier máquina. No lo es. En un servidor de archivos ocupado, el slot se reutiliza en minutos. En una workstation que nadie usa los fines de semana, el registro eliminado puede quedarse un mes. Tienes que saber qué tipo de host estás mirando antes de comprometerte con una historia sobre si algo sigue siendo recuperable.
Qué sigue conteniendo el registro
Un registro MFT eliminado es estructuralmente idéntico a uno vivo. El bit IN_USE (bit 0 del campo flags en el offset 0x16) está limpio. Todo lo demás, a menos que el registro haya sido reclamado, es lo último que NTFS escribió:
$STANDARD_INFORMATION(tipo de atributo0x10): las cuatro marcas de tiempo en SI, las banderas DOS, la referencia al descriptor de seguridad, el ID del propietario, el puntero USN. Las marcas de tiempo sobreviven a la eliminación intactas. Ten en cuenta que el SI que ves es como era el archivo en el momento de la eliminación, no cuando se creó originalmente (Windows actualiza SI constantemente mientras el archivo está vivo).$FILE_NAME(0x30): uno por hard link, más el nombre corto 8.3 en volúmenes condisable8dot3apagado. La referencia al directorio padre es el número de registro MFT del directorio donde vivía el archivo. Esa referencia se mantiene aunque el propio directorio fuera eliminado después, que es cómoflsy MFTECmd reconstruyen rutas dentro de jerarquías de directorios eliminadas.$DATA(0x80): para archivos residentes (bajo ~700 bytes de datos), los propios bytes están inline en el registro. Para archivos no residentes, la runlist apunta a los clusters que eran el archivo. Esos clusters ya no están marcados como asignados, pero no han sido puestos a cero.$ATTRIBUTE_LIST(0x20) cuando está presente, con referencias a cualquier registro de extensión que el archivo usó. Esos registros de extensión están también eliminados pero, hasta que sean reclamados, todavía parseables.
El número de secuencia es lo que hace defendible el análisis de archivos eliminados. Cada registro lleva un número de secuencia de 16 bits que se incrementa cada vez que el slot se reutiliza. Una entrada del diario USN o una referencia de $LogFile que apunta a registro 12345 secuencia 3 sigue apuntando a la secuencia 3 incluso después de que el slot sea ahora secuencia 4. Esa discrepancia es lo que te dice que el slot ha sido reutilizado desde entonces.
Cuándo desaparece realmente el slot
Dos eventos ponen fin de forma independiente a la recuperabilidad:
El slot de registro MFT es reutilizado. NTFS no tiene una estrategia de asignación fija aquí. En la práctica, cuando un archivo nuevo necesita un registro, el driver mira $MFT:$BITMAP buscando el registro libre con el número más bajo y lo usa. Los registros eliminados se reclaman aproximadamente en orden. En un volumen muy usado ese orden se mueve rápido. La propia MFT solo crece; nunca encoge, así que registros eliminados antiguos muy por encima de la marca de agua actual pueden sobrevivir años.
Los clusters de datos se sobrescriben. Independiente del registro. Los clusters se marcaron como libres en $Bitmap, así que cualquier asignador puede reclamarlos. En un archivo recién eliminado, ambos eventos tienen que suceder para que la recuperación sea irremediable. He visto registros sobrevivir pero los clusters estar perdidos hace tiempo (recuperas solo los metadatos y los datos residentes) y a la inversa (el registro fue reutilizado pero los clusters aún contienen los bytes originales y pueden ser tallados).
No hay un temporizador limpio para ninguno. "¿Cuánto duran los archivos eliminados en NTFS?" tiene la misma respuesta honesta que "¿cuánto dura un asiento libre en el bar?": hasta que alguien lo coja.
Lo que añaden los diarios
La MFT te muestra el presente. El diario USN te muestra el verbo. Un registro USN FILE_DELETE nombra el archivo, el directorio padre y la marca de tiempo de la eliminación. Aunque el slot MFT haya sido reutilizado desde entonces, la entrada USN aún preserva el nombre antiguo y el par registro/secuencia originales. Combina los dos y obtienes algo como:
2026-04-12T13:08:11Z USN FILE_DELETE | CLOSE rec=44231 seq=7 path=\Users\bob\Documents\secrets.zip
2026-04-12T13:08:11Z MFT rec=44231 IN_USE=0 seq=7 (todavía legible, eliminado)
2026-04-12T13:08:11Z MFT FN parent=12, name=secrets.zip
Esa es una respuesta reconstruible a "cómo era este archivo en el momento de la eliminación" aunque el archivo haya desaparecido por lo demás. $LogFile añade detalle a nivel de transacción en los segundos a ambos lados: la eliminación está rodeada por un par DeleteAttribute y DeallocateFileRecordSegment, y normalmente puedes identificar las operaciones cercanas.
Si VSS estaba activo y existe una instantánea de antes de la eliminación, el $MFT de la instantánea aún muestra IN_USE=1 para el mismo registro/secuencia, y los clusters de datos se preservaron por copy-on-write. Mira Volume Shadow Copy y $MFT para los detalles de extracción.
Los casos que la gente entiende mal
Herramientas de borrado seguro. SDelete en su modo predeterminado sobrescribe los clusters de datos pero no toca el registro MFT. Obtienes un registro eliminado con $FILE_NAME completo, $STANDARD_INFORMATION completo y $DATA apuntando a clusters puestos a cero. El nombre y las marcas de tiempo sobreviven absolutamente. Esto pilla por sorpresa a usuarios que esperaban que SDelete fuera más completo de lo que es.
Eliminación de archivos mediante hard links. Eliminar un hard link no elimina el archivo; el atributo $FILE_NAME para ese link se elimina y el contador de hardlinks baja. El archivo en sí solo se elimina cuando se quita el último link. Si ves un registro MFT eliminado con hardlink_count cero y sin $FILE_NAME restante, el archivo fue eliminado de verdad. Si ves un registro con un contador de hardlinks distinto de cero y un $FILE_NAME ausente, la eliminación fue parcial.
Archivos renombrados antes de la eliminación. Algunos droppers renombran su archivo de staging a un nombre benigno justo antes de eliminarlo, esperando que el $FILE_NAME superviviente parezca inocuo. El diario USN preserva el par RENAME_OLD_NAME y RENAME_NEW_NAME, así que puedes recuperar el nombre original de ahí. La MFT por sí sola solo muestra el nombre final.
La papelera de reciclaje no es una eliminación. Los archivos enviados a la papelera se renombran y se mueven a \$Recycle.Bin\<SID>\. El registro MFT permanece IN_USE=1 y el archivo está intacto bajo un nombre $R<ID>. El registro acompañante $I<ID> guarda la ruta original. Vaciar la papelera elimina entonces normalmente.
Herramientas que leen bien los registros eliminados
Para el triage echo mano de uno de:
- MFTECmd con
--de 1(drop entries) o simplemente salida sin filtrar filtrada después. Etiqueta los datos residentes y te da el número de secuencia. omerbenamram/mft_dumpcon-o json. Número de secuencia, bandera residente, lista completa de atributos. Bueno para canalizarlo a un script que saque los registros dondeIN_USE=0yseqcoincida con una referencia USN.fls -m -rdel Sleuth Kit para un bodyfile que incluya entradas eliminadas. Old-school, sigue funcionando.icat -rrecupera los datos de archivos no residentes cuyos clusters están intactos.- analyzeMFT si específicamente quieres una opción pura de Python y la velocidad no te importa.
El parser en navegador de este sitio filtra a IN_USE=0 con un clic y muestra los datos residentes inline. Si el volumen importaba, el archivo era pequeño y el slot no ha sido reutilizado, a menudo tienes los bytes delante de ti en la tabla.
Lo que todavía no puedes responder solo con la MFT
La MFT te dice que un registro existe y fue eliminado. No te dice quién lo eliminó. Para eso quieres Security 4663 (acceso a objetos) si las SACLs estaban configuradas, o Sysmon Event ID 23 (FileDelete) que registra el usuario y el proceso. En la mayoría de los hosts ninguno de los dos está habilitado. En ese caso recurres a evidencia corroborante: un hit de Prefetch para una herramienta de eliminación, una entrada de Amcache para un binario poco familiar ejecutándose en el momento adecuado, entradas de Recent File Cache de la misma ventana.
La MFT es el suelo. Construye el resto de la historia encima.
Lecturas adicionales
- Brian Carrier, File System Forensic Analysis. Los capítulos sobre semántica de eliminación NTFS siguen siendo definitivos.
- Documentación de
flsdel Sleuth Kit para la salida bodyfile canónica que incluye entradas eliminadas. - Microsoft, Master File Table. La referencia a nivel MS sobre lo que NTFS garantiza y no garantiza.