Artefactos del sistema operativo: fundamentos
Un artefacto forense es cualquier dato que un sistema operativo genera como efecto secundario de su funcionamiento normal —no porque esté pensado para vigilar al usuario, sino porque necesita esa información para funcionar— y que, leído después, revela qué ocurrió. Antes de entrar en Windows (módulos 5-6) y Linux (módulo 7) por separado, este módulo fija el vocabulario y los conceptos que ambos comparten.
- Entender las cuatro marcas de tiempo estándar (MACB) y qué evento dispara cada una.
- Distinguir metadatos del sistema de archivos de metadatos embebidos en el propio fichero.
- Conocer qué es un log del sistema y qué estructura comparten casi todos.
- Entender el concepto general de "base de datos de configuración persistente" (el registro de Windows es el caso más conocido, pero no el único) antes de verlo en detalle en el módulo 5.
- Saber por qué un único artefacto casi nunca basta, y cómo se cruzan varios para confirmar un hecho.
1. Las marcas de tiempo MACB
Casi todos los sistemas de archivos modernos guardan, como mínimo, cuatro marcas de tiempo por fichero, conocidas colectivamente por el acrónimo MACB:
| Letra | Significa | Se actualiza cuando... |
|---|---|---|
| M | Modified (modificación) | Cambia el contenido del fichero. |
| A | Accessed (acceso) | Se lee el fichero (en Windows moderno, por defecto, esta actualización está deshabilitada por rendimiento — importante saberlo para no asumir que siempre es fiable). |
| C | Changed (cambio de metadatos) / Created en NTFS según la herramienta | Cambian los metadatos del fichero (permisos, nombre) sin que cambie el contenido. En NTFS, $STANDARD_INFORMATION usa esta posición para "creación". |
| B | Birth (creación) | El fichero se crea por primera vez en ese sistema de archivos. |
2. Dos tipos de metadatos: del sistema de archivos y del propio fichero
Es fácil confundir dos cosas distintas que ambas se llaman "metadatos":
| Tipo | Dónde vive | Ejemplo |
|---|---|---|
| Metadatos del sistema de archivos | En la MFT (NTFS) o el inodo (ext4): fuera del propio fichero. | Marcas MACB, permisos, tamaño en disco. |
| Metadatos embebidos en el fichero | Dentro del propio fichero, como parte de su formato. | EXIF de una foto (modelo de cámara, coordenadas GPS, fecha de captura), autor y "última edición" de un documento de Office, metadatos de un PDF. |
La diferencia importa porque sobreviven de forma distinta: copiar un fichero a otro sistema de archivos destruye sus marcas MACB originales (se generan nuevas, con la fecha de la copia), pero no toca sus metadatos embebidos — un EXIF con coordenadas GPS viaja con la foto a cualquier sitio donde se copie, se suba o se reenvíe. Esto se trabaja a fondo en el módulo 19 (metadatos como técnica anti-forense y como fuente de error del propio atacante).
3. Logs del sistema: estructura común
Un log es, en esencia, un registro cronológico de eventos. Varían enormemente en formato (texto plano, binario, JSON, XML) pero casi todos comparten la misma información mínima:
- Marca de tiempo del evento (y su zona horaria — un detalle que causa más errores de los que debería en la reconstrucción de líneas de tiempo).
- Origen: qué proceso, servicio o componente generó el evento.
- Tipo o severidad: informativo, advertencia, error, auditoría de seguridad.
- Descripción o código de evento: qué pasó exactamente.
Windows centraliza esto en el Visor de eventos (.evtx, módulo 6); Linux lo reparte entre journald/syslog y ficheros de texto en /var/log (módulo 7). El concepto de fondo —cronología, origen, severidad, descripción— es el mismo en ambos.
4. El concepto de base de datos de configuración persistente
La mayoría de sistemas operativos necesitan un sitio donde guardar configuración que debe sobrevivir a reinicios: qué programas arrancan solos, qué dispositivos se han conectado alguna vez, preferencias de cada usuario. Windows centraliza casi todo esto en una estructura jerárquica llamada registro (módulo 5); Linux reparte el equivalente entre múltiples ficheros de configuración en texto plano (/etc, systemd units, configuración por usuario en ~/.config). El dato forense de interés es el mismo en ambos casos —qué se configuró, cuándo cambió, qué dispositivos o programas se registraron—, aunque la forma de leerlo sea completamente distinta.
5. Por qué un solo artefacto casi nunca basta
Ningún artefacto aislado es una prueba sólida por sí solo: las marcas de tiempo pueden manipularse (módulo 19), un log puede estar incompleto por rotación o por haberse desactivado, un metadato embebido puede pertenecer a una copia reenviada y no al original. Lo que sostiene una conclusión forense es la corroboración cruzada: varios artefactos independientes, generados por mecanismos distintos del sistema, que cuentan la misma historia.
$FILE_NAME de la MFT dice que un fichero se creó a las 14:03. Un evento de Windows (módulo 6) registra un inicio de sesión de ese mismo usuario a las 14:01. El historial de un navegador muestra una descarga a las 14:02. Ninguno por separado prueba nada con certeza; juntos, construyen una secuencia de hechos difícil de rebatir.Autoevaluación
- ¿Qué significan las cuatro letras de MACB y qué evento dispara cada una?
- Copias una foto con datos EXIF de GPS a un USB distinto. ¿Qué le pasa a sus marcas MACB y qué le pasa a su EXIF? ¿Por qué la diferencia?
- ¿Qué cuatro datos mínimos comparten casi todos los logs del sistema, con independencia de su formato?
- ¿Por qué un informe forense riguroso nunca cita una sola marca de tiempo como prueba definitiva de un hecho?