Linux Forensics: Artefactos y Logs Esenciales para Investigaciones

Linux en el contexto DFIR

Linux domina la infraestructura de servidores. Servidores web, bases de datos, contenedores Docker, clusters Kubernetes, firewalls, proxies y la mayoria de appliances de red corren sobre algun derivado de Linux. Cuando un incidente afecta a la infraestructura, la capacidad de analizar artefactos forenses en Linux es imprescindible.

A diferencia de Windows, donde los artefactos forenses son abundantes y variados (registry, prefetch, amcache, SRUM), Linux depende mucho mas de los logs de texto y de los metadatos del sistema de ficheros. Esto tiene ventajas (los logs de texto son faciles de parsear y buscar) y desventajas (los logs de texto son faciles de modificar o borrar).

Este articulo cubre los artefactos mas relevantes para investigaciones DFIR en sistemas Linux, desde los logs clasicos hasta los artefactos especificos de systemd.

Estructura de /var/log

El directorio /var/log es el punto central de logging en Linux. Diferentes distribuciones organizan los logs de forma ligeramente distinta, pero la estructura general es consistente.

auth.log y secure

En distribuciones Debian/Ubuntu, auth.log registra todos los eventos de autenticacion: logins exitosos y fallidos via SSH, sudo, su, PAM y otros mecanismos. En RHEL/CentOS/Fedora, el equivalente es /var/log/secure.

Este log es critico para DFIR porque revela:

Intentos de fuerza bruta contra SSH. Multiples entradas "Failed password" desde una misma IP en un periodo corto indican un ataque automatizado.

Logins exitosos con su origen. Cada login SSH exitoso registra la IP de origen, el usuario, el metodo de autenticacion (password o publickey) y el timestamp.

Escalada de privilegios via sudo. Cada invocacion de sudo queda registrada con el usuario que lo ejecuto, el comando ejecutado y si fue exitoso o denegado.

Cambios de usuario con su. Quien cambio a que usuario y cuando.

# Buscar logins SSH exitosos
grep "Accepted" /var/log/auth.log

# Buscar intentos fallidos de SSH
grep "Failed password" /var/log/auth.log

# Buscar escalada de privilegios con sudo
grep "sudo:" /var/log/auth.log | grep "COMMAND"

# Contar intentos fallidos por IP
grep "Failed password" /var/log/auth.log | \
  awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

syslog y messages

syslog (Debian/Ubuntu) o messages (RHEL/CentOS) es el log general del sistema. Recibe eventos de multiples fuentes via el demonio syslog (rsyslog, syslog-ng). Contiene eventos del kernel, servicios del sistema, cron y aplicaciones que usan la API de syslog.

Para DFIR, syslog es util para detectar:

Cambios en la configuracion de red. Interfaces que suben o bajan, cambios de IP, conexiones VPN.

Errores de servicios que pueden indicar manipulacion. Un servicio que falla repetidamente despues de cierta hora puede haber sido modificado.

Eventos de dispositivos USB. La conexion de dispositivos USB genera mensajes del kernel en syslog, incluyendo el vendor, producto y numero de serie.

kern.log

El log del kernel registra eventos de bajo nivel: drivers cargados, errores de hardware, mensajes de seguridad del kernel (SELinux, AppArmor), y eventos de red del firewall (iptables/nftables).

Los mensajes de iptables/nftables son especialmente valiosos en DFIR. Si las reglas del firewall estan configuradas para loguear conexiones bloqueadas o aceptadas, kern.log contiene un registro detallado del trafico de red con IPs de origen y destino, puertos y protocolo.

# Buscar reglas de firewall disparadas
grep "iptables" /var/log/kern.log
grep "nftables" /var/log/kern.log

# Buscar modulos del kernel cargados (posibles rootkits)
grep "module" /var/log/kern.log | grep -i "loaded\|inserted"

Logs de aplicaciones

Dependiendo de los servicios instalados, /var/log puede contener logs de:

Apache: /var/log/apache2/access.log y error.log. Cada peticion HTTP con timestamp, IP de origen, metodo, ruta, codigo de respuesta y user-agent.

Nginx: /var/log/nginx/access.log y error.log. Formato similar a Apache.

MySQL/MariaDB: logs de queries (si esta habilitado), errores y logins.

PostgreSQL: logs en /var/log/postgresql/ con queries, conexiones y errores.

Docker: logs de contenedores accesibles con docker logs o en /var/lib/docker/containers/.

Cada aplicacion tiene su propio formato de log, pero la mayoria incluyen timestamps que pueden integrarse en la super timeline.

Artefactos de sesion: wtmp, btmp, lastlog

Linux mantiene registros binarios de sesiones de usuario que complementan los logs de texto.

wtmp

/var/log/wtmp es un fichero binario que registra todos los logins y logouts del sistema, incluyendo sesiones locales, SSH, rlogin y reinicios del sistema. Se lee con el comando last.

# Ver historial de logins
last -f /var/log/wtmp

# Filtrar por usuario especifico
last -f /var/log/wtmp usuario_sospechoso

# Ver logins con IP de origen
last -f /var/log/wtmp -i

# Ver reinicios del sistema
last -f /var/log/wtmp reboot

Cada entrada en wtmp incluye: nombre de usuario, terminal (tty, pts), IP de origen (para sesiones remotas), timestamp de login, timestamp de logout y duracion de la sesion.

Busca sesiones a horas inusuales (madrugada, fines de semana), sesiones desde IPs desconocidas, y sesiones de usuarios que normalmente no acceden al sistema.

btmp

/var/log/btmp registra los intentos de login fallidos. Se lee con el comando lastb.

# Ver intentos de login fallidos
sudo lastb -f /var/log/btmp

# Contar intentos por usuario
sudo lastb -f /var/log/btmp | awk '{print $1}' | sort | uniq -c | sort -rn

Un gran numero de intentos fallidos contra el usuario root o contra usuarios especificos indica un ataque de fuerza bruta o de password spraying.

lastlog

/var/log/lastlog almacena el timestamp y la fuente del ultimo login de cada usuario del sistema. Se lee con el comando lastlog.

# Ver ultimo login de todos los usuarios
lastlog

# Filtrar usuarios que nunca se han logueado
lastlog | grep "Never"

Una cuenta de servicio que nunca deberia tener un login interactivo pero muestra un ultimo login reciente es una anomalia critica.

Historial de comandos: .bash_history y alternativas

.bash_history

El fichero ~/.bash_history de cada usuario registra los comandos ejecutados en sesiones bash. Es uno de los artefactos mas directos para entender las acciones de un atacante que ha obtenido acceso al shell.

Sin configuracion especifica, .bash_history solo contiene los comandos sin timestamps. Si HISTTIMEFORMAT esta configurado en el entorno del usuario, cada comando se precede de un timestamp Unix.

# Buscar comandos sospechosos en todos los historiales
for h in /home/*/.bash_history /root/.bash_history; do
  echo "=== $h ===";
  grep -n -i "wget\|curl\|nc \|ncat\|python -c\|base64\|chmod +x\|/tmp/" "$h" 2>/dev/null;
done

# Convertir timestamps HISTTIMEFORMAT (si existen)
# Las lineas que comienzan con # seguido de un numero son timestamps Unix

Comandos sospechosos tipicos que un atacante ejecuta incluyen:

Descarga de herramientas: wget, curl hacia URLs externas.

Reconocimiento: whoami, id, uname -a, cat /etc/passwd, ifconfig/ip addr, netstat, ps aux.

Movimiento lateral: ssh a otros hosts internos, scp para transferir archivos.

Persistencia: edicion de crontab, creacion de claves SSH autorizadas, modificacion de scripts de inicio.

Limpieza: history -c, echo "" mas redireccion al fichero .bash_history, unset HISTFILE.

Es importante que la ausencia de .bash_history o un fichero vacio son en si mismos indicadores sospechosos. Un usuario legitimo con actividad normal tendra un historial con comandos rutinarios.

Otros shells

Si el atacante uso zsh, el historial esta en ~/.zsh_history. Si uso fish, en ~/.local/share/fish/fish_history. Cada shell tiene su propio formato de historial.

Tambien verifica ~/.python_history (si Python fue usado interactivamente) y ~/.mysql_history, ~/.psql_history para sesiones de base de datos.

Crontab y mecanismos de persistencia

Los atacantes usan crontab como mecanismo de persistencia para ejecutar su malware periodicamente o para reinstalarlo si es eliminado.

Ubicaciones de crontab

Los crontabs de usuario se almacenan en /var/spool/cron/crontabs/ (Debian/Ubuntu) o /var/spool/cron/ (RHEL/CentOS). Cada fichero tiene el nombre del usuario propietario.

Los crontabs del sistema estan en:

/etc/crontab: crontab principal del sistema.

/etc/cron.d/: directorio con ficheros crontab adicionales.

/etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, /etc/cron.monthly/: scripts ejecutados con la periodicidad indicada.

# Listar crontabs de todos los usuarios
for user in $(cut -f1 -d: /etc/passwd); do
  echo "=== $user ===";
  crontab -l -u "$user" 2>/dev/null;
done

# Verificar crontabs del sistema
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

Busca entradas que ejecuten scripts desde directorios temporales (/tmp, /dev/shm), que descarguen y ejecuten contenido de URLs externas, o que tengan nombres que intentan parecerse a procesos legitimos del sistema.

Otros mecanismos de persistencia en Linux

Ademas de crontab, los atacantes pueden establecer persistencia via:

Servicios systemd: ficheros .service en /etc/systemd/system/ o ~/.config/systemd/user/. Verifica servicios creados recientemente o modificados.

Scripts de inicio: /etc/rc.local, /etc/init.d/, ~/.bashrc, ~/.profile, ~/.bash_profile. Cualquier adicion reciente a estos ficheros merece atencion.

Claves SSH autorizadas: ~/.ssh/authorized_keys. Una clave publica anadida por el atacante le permite reconectarse sin contrasena.

LD_PRELOAD: /etc/ld.so.preload o la variable de entorno LD_PRELOAD en scripts de inicio pueden cargar librerias maliciosas que interceptan llamadas del sistema (tecnica de rootkit en espacio de usuario).

Journald y systemd

En sistemas modernos con systemd, journald centraliza el logging de todos los servicios gestionados por systemd. Los logs de journald son binarios y se almacenan en /var/log/journal/ (persistente) o /run/log/journal/ (volatile, se pierde al reiniciar).

# Ver todos los logs desde una fecha
journalctl --since "2026-06-01 00:00" --until "2026-06-02 00:00"

# Filtrar por servicio
journalctl -u sshd --since "2026-06-01"

# Filtrar por prioridad (errores y criticos)
journalctl -p err..crit --since "2026-06-01"

# Ver logins via systemd-logind
journalctl -u systemd-logind --since "2026-06-01"

# Exportar a JSON para procesamiento automatizado
journalctl --since "2026-06-01" -o json-pretty > journal_export.json

# Ver logs del kernel (equivalente a dmesg pero persistente)
journalctl -k --since "2026-06-01"

Journald tiene varias ventajas sobre syslog tradicional para DFIR:

Incluye metadatos estructurados: PID, UID, GID, unidad systemd, prioridad y mas campos que facilitan el filtrado.

Es mas resistente a manipulacion que los ficheros de texto, aunque no es inmune (un atacante con root puede eliminar los ficheros de journal).

Mantiene la integridad referencial entre servicios: puedes correlacionar eventos de un servicio con los de sus dependencias.

Los ficheros de journal pueden copiarse de una imagen forense y analizarse en otro sistema con journalctl usando la opcion --directory o --file.

Sistema de ficheros: metadatos y artefactos

Timestamps del sistema de ficheros

En ext4, cada inodo tiene cuatro timestamps:

atime (access time): ultima vez que se leyeron los datos del fichero. Puede estar deshabilitado o configurado con noatime/relatime por rendimiento.

mtime (modification time): ultima vez que se modificaron los datos del fichero.

ctime (change time): ultima vez que se modificaron los metadatos del inodo (permisos, propietario, nombre). No se puede modificar directamente con touch (a diferencia de atime y mtime).

crtime (creation time): fecha de creacion del fichero. Disponible desde ext4, pero no todas las herramientas lo exponen.

Para DFIR, ctime es el timestamp mas fiable porque no puede ser modificado por un atacante sin acceso directo al disco a nivel de bloque. Si un fichero tiene un mtime de hace 2 anos pero un ctime de ayer, el atacante modifico el mtime con touch.

# Ver timestamps detallados con stat
stat /ruta/al/fichero_sospechoso

# Buscar ficheros modificados en las ultimas 24 horas
find / -mtime -1 -type f -ls 2>/dev/null

# Buscar ficheros con permisos SUID (potencial escalada de privilegios)
find / -perm -4000 -type f -ls 2>/dev/null

# Buscar ficheros en directorios temporales
find /tmp /dev/shm /var/tmp -type f -ls 2>/dev/null

Ficheros eliminados

En ext4, cuando un fichero se elimina, su inodo se marca como libre pero los datos pueden permanecer en disco hasta que los bloques se reutilicen. Herramientas como extundelete, photorec y foremost pueden recuperar ficheros eliminados de imagenes de disco.

Para verificar ficheros abiertos que han sido eliminados (tecnica usada por atacantes para ocultar ejecutables en ejecucion):

# Buscar procesos con ficheros eliminados abiertos
ls -la /proc/*/exe 2>/dev/null | grep "(deleted)"

# Ver ficheros eliminados pero abiertos
lsof +L1

Un atacante puede ejecutar un binario y luego eliminarlo del disco. El proceso sigue ejecutandose con el fichero abierto, pero no aparece en el sistema de ficheros. Este es un indicador clasico de actividad maliciosa.

Artefactos de red

Conexiones activas y puertos

En una respuesta en vivo (no imagen de disco), captura el estado de la red:

# Conexiones activas con proceso asociado
ss -tulnp
netstat -tulnp

# Conexiones establecidas (potenciales C2)
ss -tnp state established

# Tabla ARP (sistemas alcanzados en la red local)
ip neigh show
arp -a

# Tabla de rutas (modificaciones sospechosas)
ip route show

Resolucion DNS

/etc/hosts puede contener entradas anadidas por malware para redirigir trafico. /etc/resolv.conf muestra los servidores DNS configurados (un atacante puede cambiarlos para interceptar resolucion DNS).

Rotacion y manipulacion de logs

Logrotate

Linux rota los logs automaticamente usando logrotate (configurado en /etc/logrotate.conf y /etc/logrotate.d/). Los logs rotados se comprimen y se nombran con un sufijo numerico o de fecha (auth.log.1, auth.log.2.gz).

En una investigacion, analiza todos los ficheros rotados, no solo el log activo. La actividad del atacante puede estar en un log rotado si el incidente ocurrio hace dias o semanas.

Deteccion de manipulacion

Los atacantes con acceso root pueden editar o eliminar logs. Para detectar manipulacion:

Compara timestamps entre fuentes redundantes. Si auth.log muestra un login a las 14:00 pero wtmp no tiene registro para ese timestamp, uno de los dos ha sido manipulado.

Busca gaps en la secuencia temporal. Entradas consecutivas con una diferencia de horas cuando normalmente hay entradas cada pocos segundos indican que se han eliminado entradas intermedias.

Verifica la coherencia del tamano del fichero con el volumen de datos esperado. Un auth.log de solo 10 KB en un servidor con mucha actividad SSH es sospechoso.

Comprueba si los logs remotos (si estan configurados) coinciden con los locales. Si la empresa envia logs a un SIEM via syslog remoto, las discrepancias entre los logs locales y los remotos indican manipulacion local.

Conclusion

La forense de Linux depende fundamentalmente de los logs del sistema y de los metadatos del sistema de ficheros. A diferencia de Windows, donde hay artefactos especializados para casi cada tipo de actividad, en Linux la informacion esta mas dispersa y depende mucho de la configuracion del sistema (que logs estan habilitados, con que nivel de detalle, y si se mantienen de forma persistente o volatile).

Los puntos clave para el analista DFIR son: verificar siempre multiples fuentes de logs para detectar inconsistencias, no confiar en un solo artefacto, prestar atencion a las ausencias (ficheros eliminados, historiales vacios, gaps en logs), y documentar la configuracion de logging del sistema como parte de la adquisicion de evidencia.

La combinacion de auth.log, wtmp, .bash_history, crontab y journald proporciona la base para reconstruir la mayoria de los incidentes en sistemas Linux, desde intrusiones via SSH hasta compromisos de aplicaciones web y movimiento lateral en redes corporativas.