$MFT es el índice que NTFS usa para llevar el control de cada archivo y directorio en un volumen. También es el artefacto más informativo que puedes extraer de una máquina Windows. Cualquier otro archivo del volumen, la propia tabla incluida, tiene al menos un registro dentro. Las herramientas forenses responden a preguntas difíciles sobre archivos cuya existencia Windows ya no admite, porque los registros sobreviven a la eliminación. Los threat hunters persiguen la persistencia a través de ella porque los atacantes no pueden mover archivos en NTFS sin escribir en ella. Si solo vas a aprender un artefacto de Windows a nivel de bytes, que sea este.
Esta es la referencia que me hubiera gustado tener al empezar. Cubre qué es la tabla, cómo es un registro, qué atributos puede llevar un registro, qué significan los archivos de sistema reservados al inicio, qué significa realmente el temido error "Windows no puede recuperar la master file table", y cómo leer la tabla tú mismo.
Qué es la Master File Table
$MFT es un archivo. Un único archivo. Se sitúa en un offset conocido cerca del inicio de cada volumen NTFS. El sector de arranque en el offset 0 de la partición (los 512 bytes del BIOS Parameter Block) contiene un campo llamado MftStartLcn que apunta al primer cluster de $MFT. Lee esos 1.024 bytes y tienes el registro 0, la autodescripción de la tabla.
Cada fila de la tabla tiene exactamente 1.024 bytes y describe un archivo o un directorio. Cada registro contiene el nombre, marcas de tiempo, banderas estilo DOS, referencia al descriptor de seguridad y, o bien los datos en sí (archivos pequeños) o una lista de clusters de disco donde residen los datos (archivos grandes), todo codificado como una secuencia de atributos tipados.
NTFS se introdujo con Windows NT 3.1 en 1993 y ha sido el sistema de archivos predeterminado de Windows en todo disco fijo desde Windows XP. Reemplazó a FAT, que mantiene una pequeña tabla de asignación y guarda los nombres de archivo dentro de las entradas de directorio. NTFS pone casi cada pieza de metadatos de cada archivo en una sola tabla estructurada, $MFT. Ese diseño tiene dos consecuencias que vale la pena memorizar:
- Todos los metadatos están en un solo lugar. Un único seek a
$MFTenumera cada archivo del volumen. Por eso las herramientas forenses, motores antivirus, servicios de indexación y software de copia de seguridad lo leen. También por eso una$MFTcorrupta es un problema mucho mayor que una FAT corrupta. - Los archivos eliminados dejan sus metadatos. Cuando NTFS elimina un archivo, borra un bit en la cabecera del registro y marca los clusters del archivo como libres en
$Bitmap. El resto del registro (nombre, marcas de tiempo, a menudo los datos) permanece intacto hasta que se reutiliza esa plaza de registro. Mira qué sobrevive a una eliminación.
El acrónimo MFT significa Master File Table. Se escribe $MFT en disco porque, en NTFS, el signo dólar prefija los nombres de los archivos de metadatos.
Cómo se distribuye $MFT en el disco
Cuando NTFS formatea un volumen, reserva una región llamada zona MFT cerca del inicio de la partición. Los primeros 16 registros de la tabla están reservados para archivos de metadatos de NTFS (descritos abajo); el registro 0 es la propia entrada de la tabla, apuntando a sus propios clusters.
$MFT crece extendiéndose en su zona reservada cuando necesita más registros. Si el volumen se llena antes de agotar la zona, Windows reduce la zona para hacer hueco a los datos del usuario, por lo que una $MFT muy fragmentada es habitual en sistemas de archivos envejecidos. La tabla nunca encoge. Una vez creada una plaza, permanece en $MFT; la eliminación solo borra la bandera "en uso". Por eso los registros eliminados antiguos muy por encima de la marca de agua actual pueden sobrevivir años en un volumen poco usado.
Una copia de respaldo de los primeros registros vive en $MFTMirr, situada en el medio del volumen. Si la propia $MFT no se puede leer, NTFS usa $MFTMirr para arrancar la recuperación. Mira $MFTMirr y cuándo lo usa NTFS.
Anatomía de un registro FILE
Cada registro MFT comienza con la firma ASCII de cuatro bytes FILE (46 49 4C 45). Los registros corruptos llevan BAAD en su lugar, una lápida que escribe chkdsk cuando no pudo reparar el registro. Tras la firma viene una cabecera de 56 bytes, luego el array de fixup, luego un flujo de atributos tipados terminado por 0xFFFFFFFF.
La cabecera contiene los campos a los que recurrirás con más frecuencia:
- Firma.
FILEpara un registro válido,BAADpara no reparable. - Array de actualización de secuencia (fixup). El truco para detectar escrituras desgarradas. Los dos últimos bytes de cada bloque de 512 bytes del registro se sustituyen por una USN; los originales se guardan en este array. Al leer, NTFS verifica la USN y restaura los bytes originales.
- Número de secuencia de
$LogFile. Un puntero a$LogFilepara la recuperación tras un fallo. - Número de secuencia. Se incrementa cada vez que se reutiliza la plaza del registro. Combinado con el número de registro forma la referencia de archivo de 64 bits que identifica de manera única una encarnación particular de un archivo.
- Recuento de hard links. Número de atributos
$FILE_NAMEque apuntan al registro. - Banderas. El bit 0 es
IN_USE(limpio significa eliminado). El bit 1 esDIRECTORY. - Referencia al registro de archivo base. No es cero en registros de extensión que pertenecen a un registro base en otra parte de la tabla.
- Tamaño usado y asignado. Usado es cuánto del slot de 1.024 bytes ocupa realmente este registro; asignado es el tamaño del slot (siempre 1.024 en volúmenes estándar).
Para un recorrido byte a byte por la cabecera y el flujo de atributos, mira dentro de un registro MFT.
Tras la cabecera vienen los atributos. Cada uno tiene su propia cabecera corta (tipo, longitud, bandera residente/no residente, nombre opcional) seguida de los datos. No hay un orden fijo, pero en la práctica $STANDARD_INFORMATION va primero y $DATA al final. Un registro al que se le acaba el espacio (demasiados fragmentos, demasiados ADS, un nombre inusualmente largo) genera un atributo $ATTRIBUTE_LIST que apunta a uno o más registros de extensión en otra parte de la tabla. Los parsers deben seguir la cadena para reconstruir el archivo.
Atributos de archivo guardados en $MFT
Esta es la lista canónica de tipos de atributo NTFS, con códigos hexadecimales:
| Tipo | Hex | Propósito |
|------|-----|---------|
| $STANDARD_INFORMATION | 0x10 | Cuatro marcas de tiempo (creado, modificado, accedido, MFT-modificado), banderas DOS, ID de propietario, ID de seguridad, puntero USN. |
| $ATTRIBUTE_LIST | 0x20 | Punteros a registros de extensión cuando los atributos de un archivo desbordan un registro. |
| $FILE_NAME | 0x30 | Un nombre de archivo, referencia al directorio padre, tamaño asignado y real, y un segundo conjunto de cuatro marcas de tiempo. Un archivo puede tener varios (uno por hard link, más el nombre corto 8.3 en volúmenes que lo tienen habilitado). |
| $OBJECT_ID | 0x40 | Identificador de objeto de 128 bits usado por el servicio Distributed Link Tracking. |
| $SECURITY_DESCRIPTOR | 0x50 | ACL por archivo (legado). NTFS moderno guarda las ACL centralmente en $Secure y las referencia por ID desde $STANDARD_INFORMATION. |
| $VOLUME_NAME | 0x60 | Solo en el registro 3 ($Volume). Contiene la etiqueta del volumen. |
| $VOLUME_INFORMATION | 0x70 | Versión NTFS, bandera dirty. |
| $DATA | 0x80 | Contenido del archivo. Residente para archivos muy pequeños; no residente (una runlist de clusters) en caso contrario. Un archivo puede llevar varios atributos $DATA; el sin nombre es el flujo primario, los nombrados son alternate data streams. |
| $INDEX_ROOT | 0x90 | Raíz de un árbol B+. Usado por directorios ($I30), índices de reparse point y otras estructuras indexadas. |
| $INDEX_ALLOCATION | 0xA0 | Continuación no residente de un índice grande. |
| $BITMAP | 0xB0 | Bitmap de asignación para la propia $MFT o para directorios grandes. |
| $REPARSE_POINT | 0xC0 | Symlinks, junctions, puntos de montaje, marcadores OneDrive, stubs de deduplicación. |
| $EA_INFORMATION / $EA | 0xD0 / 0xE0 | Atributos extendidos de la era OS/2. Raros en Windows moderno. WSL1 los usaba para metadatos POSIX, el único contexto que vale la pena recordar. |
| $LOGGED_UTILITY_STREAM | 0x100 | Metadatos de cifrado EFS ($EFS), datos de transacciones TxF. |
Un registro siempre lleva al menos $STANDARD_INFORMATION, un $FILE_NAME y un $DATA. Todo lo demás es opcional y dependiente de funcionalidades.
Datos residentes vs no residentes
La mayoría de los atributos $DATA en un volumen real son no residentes: la cabecera del atributo lleva una lista compacta de runs de cluster (un LCN inicial más una longitud, repetidos), y los bytes del archivo residen en otra parte del disco. La cabecera del atributo en sí es pequeña.
Si el archivo es lo bastante pequeño (típicamente bajo ~700 bytes una vez contabilizados los demás atributos), NTFS guarda los bytes en línea dentro del registro. Eso son datos residentes, y es uno de los artefactos más útiles en el trabajo forense: el contenido de un pequeño archivo de texto eliminado hace semanas puede seguir, byte por byte, dentro de un registro $MFT no asignado. Mira datos residentes para el umbral de tamaño y qué buscar.
Archivos de metadatos NTFS en los primeros dieciséis registros
Los primeros 16 registros de $MFT están reservados para la contabilidad de NTFS. Empiezan con $ para no colisionar con nombres de archivo de usuario. Los que vale la pena conocer:
| Nº Rec. | Archivo | Qué es |
|-------|------|------------|
| 0 | $MFT | La propia tabla. Su runlist $DATA apunta a sus propios clusters. |
| 1 | $MFTMirr | Copia parcial de los primeros registros de $MFT. |
| 2 | $LogFile | Registro de transacciones usado para deshacer o rehacer operaciones incompletas tras un crash. |
| 3 | $Volume | Etiqueta del volumen y bandera dirty. |
| 4 | $AttrDef | Esquema de los tipos de atributo válidos. |
| 5 | . | El directorio raíz. |
| 6 | $Bitmap | Un bit por cluster del volumen; rastrea la asignación. |
| 7 | $Boot | Copia del sector de arranque. |
| 8 | $BadClus | Archivo sparse cuyos runs apuntan a cada cluster que el sistema de archivos ha marcado como defectuoso. |
| 9 | $Secure | Almacén central de descriptores de seguridad. |
| 10 | $UpCase | Tabla de mapeo a mayúsculas Unicode usada para la comparación de nombres sin distinguir mayúsculas. |
| 11 | $Extend | Directorio que contiene archivos de sistema más nuevos: $ObjId, $Quota, $Reparse, $UsnJrnl, $RmMetadata. |
El journal de cambios $UsnJrnl (bajo $Extend) es especialmente útil en forense; registra cada cambio de metadatos en el volumen y complementa $MFT para la reconstrucción de la línea temporal. Mira emparejar journal con tabla de archivos.
Cuando $MFT falla
El error "Windows no puede recuperar la master file table. CHKDSK abortado" aparece cuando chkdsk no puede leer $MFT y tampoco puede recurrir a $MFTMirr. Para ese momento NTFS ya ha intentado y fallado su autorreparación integrada. Las causas que he visto, ordenadas por cuán frecuentemente resultan ser cada una:
- Medio físico fallando. Sectores defectuosos en la zona MFT devuelven basura al leer. Los datos SMART suelen corroborarlo. Imagina el disco con
ddrescue, no condd, y trabaja sobre la imagen. - Pérdida súbita de energía durante una operación intensa de metadatos. El registro de transacciones normalmente las revierte, pero un
$LogFilecorrupto vence al rollback. - Corrupción a nivel de driver o filtro. Stacks de cifrado de disco defectuosos, minifiltros de sistema de archivos, o drivers de almacenamiento con bugs pueden escribir registros inconsistentes. Habitual en hosts con varios agentes de seguridad luchando entre sí.
- Sobrescrituras maliciosas. Los wipers y un puñado de familias de ransomware (notablemente Petya y la primera ola de NotPetya) garabatean deliberadamente sobre
$MFTpara hacer el volumen no montable. Mira patrones de ransomware en MFT.
La respuesta forense correcta:
- Deja de escribir en el volumen inmediatamente. Cada escritura posterior reduce la posibilidad de recuperación.
- Imagina el disco con FTK Imager,
ddoddrescuea un destino conocido. Verifica el hash. - Trabaja sobre la imagen, no sobre el original. Prueba
testdisk,R-Studioo un parse manual que encuentre registrosFILEescaneando firmas directamente sobre el volumen. Aunque el puntero en disco a$MFThaya desaparecido, los propios registros siguen siendo normalmente reconocibles. - Si el objetivo es poner el volumen de nuevo en línea en vez de recuperar datos, solo entonces ejecuta
chkdsk /fsobre la imagen.
chkdsk /b en un volumen escribible puede limpiar marcas de cluster defectuoso, pero también puede descartar registros que no entiende. Ejecútalo sobre el original solo después de tener una imagen y haber decidido que la disponibilidad supera a la fidelidad forense.
Cómo leer $MFT
Tienes tres opciones realistas:
- MFTECmd (Eric Zimmerman). Una CLI de Windows que produce CSV en la disposición compatible con bodyfile que la mayoría de herramientas de timeline esperan. El estándar de facto para respondedores de incidentes.
omerbenamram/mft. Un crate de Rust y CLI (mft_dump). El parser que usa este sitio, útil cuando quieres scriptar el análisis o incrustarlo en una pipeline mayor.- El parser en navegador de este sitio. Suelta
$MFTen la página de inicio y ejecuta el mismo parser de Rust, compilado a WebAssembly, enteramente en tu navegador. Nada se sube.
Para una comparación con pros y contras concretos, mira herramientas de parser MFT. Para flujos de trabajo prácticos sobre una $MFT parseada, mira construir una línea temporal, archivos eliminados y extraer $MFT.
Preguntas frecuentes
¿Qué significa MFT?
MFT significa Master File Table. Se escribe $MFT en disco porque, en NTFS, el signo dólar prefija los nombres de los archivos de metadatos.
¿Para qué se usa la master file table?
Es el índice que NTFS usa para encontrar cada archivo y directorio en un volumen. Cada entrada almacena el nombre del archivo, las marcas de tiempo, la información de seguridad, los atributos y la ubicación de sus datos en disco.
¿Qué atributos de archivo se guardan en la master file table?
Como mínimo cada registro lleva $STANDARD_INFORMATION (marcas de tiempo, banderas DOS), $FILE_NAME (nombre y un segundo conjunto de marcas de tiempo) y $DATA (contenido del archivo o un puntero a él). Los registros pueden llevar también $ATTRIBUTE_LIST, $OBJECT_ID, $SECURITY_DESCRIPTOR, $INDEX_ROOT, $INDEX_ALLOCATION, $BITMAP, $REPARSE_POINT, $EA y $LOGGED_UTILITY_STREAM según el archivo. La referencia completa está en la tabla de atributos arriba.
¿Qué tamaño tiene la master file table?
Cada registro mide 1.024 bytes. La tabla reserva en torno al 12,5% del volumen por defecto (la zona MFT) pero solo consume el espacio que realmente necesita. Un volumen con un millón de archivos tiene una $MFT de aproximadamente 1 GB.
¿Es $MFT lo mismo que $MFTMirr?
No. $MFTMirr es una copia parcial de los primeros pocos registros de $MFT, situada en otro lugar del disco para que NTFS pueda arrancar la recuperación si la cabecera de la tabla principal está corrupta.
¿Cómo arreglo una master file table corrupta?
Imagina el disco primero. Luego, o bien ejecuta chkdsk /f contra la imagen (rápido, puede descartar registros), o usa una herramienta de recuperación capaz de escanear firmas FILE y reensamblar la tabla desde clusters crudos (lento, preserva más evidencia). Nunca ejecutes chkdsk contra el volumen original antes de imaginarlo.
¿Puedo leer $MFT en Linux o macOS?
Sí. $MFT es solo un archivo. Cualquier parser que acepte un volcado crudo de $MFT funciona en cualquier OS: omerbenamram/mft, analyzeMFT, la herramienta web de este sitio. Solo necesitas Windows para extraer el archivo de un volumen montado en vivo.
Lecturas adicionales
- Microsoft, Master File Table. La referencia oficial, escueta.
- Brian Carrier, File System Forensic Analysis. Sigue siendo el mejor libro sobre el diseño y la recuperación de NTFS.
- La documentación NTFS del proyecto linux-ntfs. Offsets de campo para cada atributo, obtenidos por ingeniería inversa a pulso.