Parte: 9 — Forense digital y respuesta a incidentes · Fuente: Brian Carrier — File System Forensic Analysis ⏱️ Duración estimada: 130 min · Nivel: Avanzado
Entender la anatomía interna de NTFS y ext4 al nivel que permite hacer forense real: la MFT y sus atributos, marcas de tiempo, el $LogFile y $UsnJrnl en NTFS; inodos, journal y timestamps en ext4. Al terminar podrás reconstruir la historia de un archivo aunque haya sido borrado o manipulado.
Al finalizar, el alumno podrá:
$UsnJrnl y el journal de ext4 para reconstruir cambios.| # | Tema | Por qué importa |
|---|---|---|
| 1 | MFT y registros de archivo | Corazón de NTFS |
| 2 | Atributos $STANDARD_INFORMATION y $FILE_NAME |
Dos juegos de timestamps |
| 3 | Timestamps MACB | Reconstruyen actividad |
| 4 | $LogFile y $UsnJrnl |
Historial de cambios NTFS |
| 5 | Inodos y bloques en ext4 | Corazón de ext4 |
| 6 | Journal de ext4 (jbd2) | Cambios recientes |
| 7 | Archivos borrados y residuos | Recuperación de metadatos |
| 8 | The Sleuth Kit | Herramienta de análisis |
$STANDARD_INFORMATION: atributo con timestamps que el usuario puede modificar fácilmente. Característica: manipulable por timestomping.$FILE_NAME: atributo con timestamps que solo el kernel actualiza. Característica: útil para detectar manipulación de tiempos.$UsnJrnl: Update Sequence Number Journal, registra cambios en archivos. Característica: revela creaciones/borrados recientes.fls, istat, icat, mmls, fsstat, mactime.analyzeMFT.py, MFTECmd (Eric Zimmerman), UsnJrnl2Csv.debugfs, extundelete.Usa una imagen
.ddpropia (por ejemplo de un pendrive formateado en NTFS y otro en ext4).
bash
mmls caso001.dd
bash
fsstat -o 2048 caso001.dd
*):bash
fls -r -o 2048 caso001.dd
bash
istat -o 2048 caso001.dd 128
bash
icat -o 2048 caso001.dd 128 > recuperado.bin
bash
fls -r -m C: -o 2048 caso001.dd > bodyfile.txt
mactime -b bodyfile.txt -d > timeline.csv
bash
MFTECmd.exe -f "$MFT" --csv salida --csvf mft.csv
Compara los timestamps de $STANDARD_INFORMATION y $FILE_NAME para detectar timestomping.
8. En ext4, explora con debugfs:
bash
debugfs -R "stat <2>" imagen_ext4.dd
$SI y $FN en una MFT de ejemplo.icat y verifica su contenido.debugfs para listar los inodos borrados de una imagen ext4.A partir de una imagen NTFS propia donde borraste un archivo y le manipulaste los tiempos, demuestra con evidencia de la MFT que hubo timestomping y recupera el contenido original del archivo borrado.
Criterio de aceptación: presentas (a) el archivo recuperado con icat, (b) una comparación $SI vs $FN que muestra la incoherencia de timestamps, y (c) una explicación de por qué esa incoherencia indica manipulación.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
fls no muestra offset correcto |
Falta -o con el sector de inicio de la partición. Sácalo de mmls. |
icat devuelve datos basura |
El inodo fue reasignado; los bloques ya se sobrescribieron. |
| Timestamps "imposibles" (futuro) | Timestomping o reloj alterado. Contrasta con $FN. |
extundelete no recupera nada |
ext4 limpió los punteros del inodo. Prueba carving (clase 214). |
MFTECmd no encuentra $MFT |
Debes extraer $MFT con FTK Imager primero. |
❓ ¿Por qué hay dos juegos de timestamps en NTFS?
$STANDARD_INFORMATION lo actualizan apps y usuarios; $FILE_NAME solo el kernel. Compararlos delata manipulación.
❓ ¿ext4 conserva archivos borrados? Menos que NTFS: suele limpiar los punteros del inodo. A veces el journal ayuda, y siempre queda el carving.
❓ ¿Qué es un archivo residente? Uno tan pequeño que sus datos caben dentro del propio registro de la MFT, sin ocupar clusters aparte.
❓ ¿El $UsnJrnl está siempre activo?
En Windows moderno normalmente sí. Es una fuente riquísima de creaciones, renombres y borrados recientes.
Clase 203 — Adquisición forense: discos e imágenes