Wazuh me avisa cuando pasa algo raro en mi máquina. Si mañana esa alerta fuera un incidente de verdad, ¿podría explicar qué pasó, en qué orden y con qué evidencia? Hoy, a medias. Esa parte, reconstruir los hechos y dejarlos documentados para que otro los pueda revisar, es la forense digital, y es donde más flojo estoy.

Así que me puse a estudiarla. Acá cuento por qué la elegí, cómo encaja en ARGUS (el proyecto personal con el que me estoy formando para trabajar en un CSIRT) y cómo organicé el estudio para no sumar otra pila de cursos empezados.

Dónde estaba ARGUS

En agosto conté el plan original: un roadmap largo, un catálogo de certificaciones gratuitas, un lab con Wazuh, TheHive y Cortex en Docker sobre Arch, y 34 tareas repartidas en fases. A las pocas semanas me di cuenta de que el plan asumía que arrancaba de cero.

Hace tres años que trabajo en IAM en entornos productivos, y Linux, redes, hardening y lectura de logs los uso todos los días. Tener tareas para aprender eso no me aportaba nada. Encima, mirar una lista de 34 casillas sin tildar me desanimaba más de lo que me empujaba.

Así que recalibré. Las tareas que repetían cosas que ya sé las junté en un checklist que se resuelve en una tarde, solo para confirmar que efectivamente las sé. El resto lo agrupé en cinco tracks, cada uno con su objetivo y un entregable para publicar:

  • DFIR (forense de disco, memoria y timeline).
  • Análisis de malware y reversing.
  • Threat intelligence y hunting.
  • Detection engineering.
  • Operación de SOC y automatización, con un capstone al final.

Los cuatro primeros son los huecos que encontré en lo que sé. El quinto los cruza en un ejercicio final: simular un ataque completo contra mi lab y responderlo entero, desde la alerta hasta el reporte.

Por qué arranqué por forense

Triagear una alerta y investigar un incidente son trabajos distintos. Cuando triageás, mirás la alerta, decidís si es real y la escalás. Cuando investigás, agarrás un sistema comprometido, reconstruís qué pasó y escribís un reporte que aguante que alguien más lo revise con lupa. En un CSIRT te piden las dos cosas, y yo solo practiqué la primera.

También pesó que forense está debajo de los otros tracks. Para analizar malware necesitás evidencia bien adquirida; para hacer hunting tenés que saber qué rastros deja cada técnica. Y responder a un incidente sin forense termina siendo contener y cruzar los dedos.

Y hay algo que me resulta familiar. En IAM me paso buena parte del tiempo contestando quién tuvo acceso a qué, desde cuándo y por qué, y dejándolo auditable. En forense la pregunta se parece bastante, solo que llega después del hecho y la única fuente que tenés es la evidencia.

Un libro como hilo conductor

Mi primera versión del track era una lista de recursos sueltos: el curso DFIR Foundations de BlueCape, una tarea de Volatility, labs de CyberDefenders. Todos buenos. El problema es que me conozco: con diez recursos y ningún orden, termino saltando de uno a otro sin cerrar ninguno.

El 10 de noviembre reorganicé el track alrededor de un libro, Análisis forense digital. Metodologías, herramientas y aplicaciones, de Rafael Socas Gutiérrez y Luis Gómez Déniz (Marcombo, 2026). Me convenció que cada capítulo trae un test, ejercicios resueltos y un proyecto práctico con artefactos descargables y su solución, o sea, todo lo que necesito para estudiar solo y saber si lo estoy haciendo bien.

Cada capítulo pasó a ser un módulo. El primero es metodología: adquisición, cadena de custodia, metadatos y anti-forense. Después vienen Windows (memoria RAM con FTK Imager y Volatility, registro, logs), Linux (volcado con AVML, cuentas, cron), tráfico de red con Wireshark y tcpdump, malware con YARA y fuzzy hashing, y por último correo electrónico y análisis de cabeceras.

Los recursos que ya tenía quedaron colgados del módulo que les corresponde. BlueCape lo hago en paralelo con el capítulo 1 porque cubre el mismo marco desde otro lado. La tarea de Volatility sobre mi propio Arch se convirtió en la práctica del capítulo de Linux. Y CyberDefenders lo dejo para el final, para sumar horas de práctica cuando ya tenga el libro terminado.

Cómo estudio cada módulo

Todos los módulos siguen el mismo ciclo:

  1. Leo el capítulo y anoto solo lo nuevo. Si algo ya lo tengo en mi vault de Obsidian, pongo el link y sigo.
  2. Hago el test sin mirar y lo corrijo con el anexo del libro.
  3. Intento los ejercicios resueltos antes de leer la resolución.
  4. Hago el proyecto práctico en una VM, con los artefactos originales.
  5. Busco una práctica externa del mismo tema con evidencia menos guiada: imágenes de NIST CFReDS, MemLabs para memoria de Windows, Malware Traffic Analysis para red.
  6. Escribo un mini-reporte de una página con la pregunta, la evidencia, las herramientas, los hallazgos y la conclusión.

Me puse una regla que sé que me va a costar: el PDF con la solución del proyecto lo abro recién cuando mi reporte está escrito. Si lo leo antes, termino copiando los pasos y me pierdo justamente la parte de pensar qué buscar.

La evidencia se trata como evidencia

Los archivos del libro son de práctica (una foto, un PCAP, un par de mails), pero decidí manejarlos como si fueran de un caso real. Quiero que el procedimiento correcto me salga sin pensarlo, y eso se logra repitiéndolo desde el primer ejercicio.

Cada capítulo tiene tres carpetas: evidencia/ con los originales en solo lectura, trabajo/ para las copias y lo que generan las herramientas, y reporte/ para el entregable. Antes de tocar nada, hasheé cada original: 

# Originales en solo lectura, para no modificarlos por accidente
chmod -R a-w Cap*/evidencia/

# Hash SHA-256 de cada original, guardado aparte
sha256sum Cap*/evidencia/* > HASHES-evidencia-original.sha256

# Antes y después de cada sesión: verificar que nada cambió
sha256sum -c HASHES-evidencia-original.sha256

# Se trabaja siempre sobre una copia
cp Cap1/evidencia/Imagen_Analisis.jpg Cap1/trabajo/

Es lo más básico de la cadena de custodia, y me parece mejor tenerlo automatizado antes de llegar a un volcado de memoria de varios gigas. De hecho, el primer proyecto del libro va de esto: dos imágenes que a simple vista son iguales, y hay que demostrar con hashes y metadatos cuál fue modificada.

Dónde estoy hoy

Estoy en el arranque. El track está armado, el material del libro organizado y hasheado, y lo próximo es el capítulo 1 junto con BlueCape. Después me toca armar una workstation forense en Arch con las herramientas que usa el libro (Autopsy, Volatility 3, AVML, bulk_extractor, Wireshark, YARA, ssdeep) y una VM con Windows para FTK Imager. Prefiero esperar a terminar el primer capítulo para instalarla; así sé qué voy a usar de verdad.

El entregable del track es un caso forense mío, de principio a fin: comprometer a propósito mi host o una VM, adquirir la evidencia, armar la timeline y publicar el reporte acá. Hasta entonces voy a ir escribiendo sobre cada módulo a medida que lo termine, incluido lo que me salga mal.

Si también estás arrancando con forense, lo que a mí me destrabó fue elegir un recurso central y colgar el resto de ahí. Con el mío ya elegido, ahora toca sentarse con el capítulo 1.

Referencias