Análisis forense de logs Linux: auth.log, journal y auditd

En resumen. Un host Linux registra la misma intrusión en hasta cuatro lugares independientes: los logs de texto escritos por rsyslog (auth.log, secure, syslog, messages), el journal de systemd en formato binario, el log de auditoría escrito por auditd y los registros de inicio de sesión binarios (wtmp, btmp, utmp, lastlog o sus sucesores en SQLite). Cada uno responde a una pregunta distinta, cada uno puede faltar por un motivo inocente, y un atacante rara vez limpia los cuatro. La investigación consiste en compararlos.

Cuatro fuentes, cuatro preguntas

Fuente	Archivos	Responde a	Punto ciego
Logs de texto	`/var/log/auth.log`, `syslog` (Debian, Ubuntu); `/var/log/secure`, `messages` (familia RHEL)	Quién se autenticó, desde dónde y con qué método; líneas de comando de sudo; cambios de cuentas	Hora local, a veces sin año; el nombre del programa no está verificado
Journal de systemd	`/var/log/journal/<machine-id>/*.journal`	Los mismos mensajes más `_PID`, `_UID`, `_EXE`, `_SYSTEMD_UNIT` de confianza, horas UTC en microsegundos, IDs de arranque	Binario, retención por tamaño, puede ser solo volátil
auditd	`/var/log/audit/audit.log`	Inicios de sesión y sesiones de PAM, y cada programa ejecutado cuando existe una regla de execve, vinculados al usuario de inicio de sesión (`auid`)	Solo lo que cubren las reglas; no se instala por defecto en Debian ni en Ubuntu
Registros de inicio de sesión	`/var/log/wtmp`, `btmp`, `lastlog`, `/run/utmp`, `wtmp.db`, `lastlog2.db`	Sesiones interactivas con inicio y fin, inicios de sesión fallidos, último inicio de sesión por cuenta, reinicios	El SSH no interactivo suele faltar; trivial de editar como root

El journal de systemd y rsyslog suelen contener copias solapadas de la misma línea, escritas y rotadas de forma independiente. auditd se alimenta del kernel, no de syslog. Los archivos wtmp y btmp los escriben directamente login, sshd y PAM. Esa independencia es lo que convierte una línea de tiempo unificada en algo más que una comodidad: es lo que hace visibles los borrados y las ediciones.

Cómo se ve un inicio de sesión SSH en cada fuente

Tomemos un único inicio de sesión con contraseña de svc_backup desde 203.0.113.45:

auth.log: sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2, después pam_unix(sshd:session): session opened y después systemd-logind[845]: New session 7 of user svc_backup.
Journal: los mismos tres mensajes, cada uno con _PID, _UID, _SYSTEMD_UNIT=ssh.service y una marca de tiempo UTC en microsegundos.
audit.log: USER_AUTH, USER_ACCT, LOGIN (que fija auid=1001 ses=114), USER_START y USER_LOGIN con addr=203.0.113.45 res=success.
wtmp: un registro USER_PROCESS en pts/1 con host 203.0.113.45; al cerrar la sesión, un registro DEAD_PROCESS en la misma línea.
lastlog: la ranura del UID 1001 sobrescrita con la hora, pts/1 y 203.0.113.45.

Aparecen tres identificadores de sesión: el PID de sshd (3071), el número de sesión de systemd-logind (7) y la sesión de auditoría (ses=114). Son números distintos para el mismo inicio de sesión. Reconstruir una sesión significa vincularlos: las líneas PAM session opened y session closed comparten el PID de sshd, la sesión de logind se anuncia a milisegundos de ellas, y cada registro de auditoría intermedio lleva ses=114, incluidos los comandos ejecutados después en una shell de root.

Dónde discrepan las fuentes y por qué

Las discrepancias son normales. Antes de hablar de manipulación, descarta las explicaciones inocentes:

No hay auth.log. Las instalaciones de Debian 12 y de Fedora recientes pueden no ejecutar rsyslog. En ese caso, el journal es el único log del sistema.
El journal empieza más tarde que auth.log. El journal tiene un límite de tamaño (10 % del sistema de archivos, con un máximo de 4G por defecto) y puede ser volátil (/run/log/journal) si no está habilitado el almacenamiento persistente.
Comando SSH sin registro en wtmp. ssh host command, scp y sftp no asignan un terminal y a menudo no dejan entrada en wtmp.
No hay registros execve. No se cargó ninguna regla de auditoría para execve. Lee primero /etc/audit/rules.d/.
Horas distintas. Las líneas syslog tradicionales están en hora local y sin año; el journal y el log de auditoría están en UTC. Un desfase de una hora suele ser una zona horaria, no un atacante.

Lo que queda tras estas comprobaciones es lo interesante: líneas de autenticación presentes en el journal pero ausentes de auth.log, huecos en los números de secuencia del journal, un registro de wtmp lleno de ceros, una hora de lastlog sin sesión correspondiente en wtmp. La guía sobre manipulación repasa cada uno de estos casos.

Primero, normalizar la hora

Una línea de tiempo unificada solo es tan buena como su gestión de la hora:

Syslog RFC 3164 (Sep 14 10:02:11) no tiene año ni zona. La zona se obtiene de /etc/localtime o /etc/timezone en la imagen; el año se calcula hacia atrás a partir de la fecha de modificación del archivo, con atención a un cambio de año dentro del archivo. Consulta syslog RFC 3164.
Las líneas RFC 3339 de alta precisión (2026-09-14T10:02:11.482113+00:00), el formato por defecto en Ubuntu 24.04 y Debian 12+, incluyen su desfase y los microsegundos.
Las líneas RFC 5424 procedentes de reenviadores también incluyen una marca de tiempo completa.
Las horas del journal son microsegundos desde la época Unix, en UTC. journalctl muestra _SOURCE_REALTIME_TIMESTAMP (cuándo se generó el mensaje) si la entrada lo tiene.
Las marcas de audit.log son msg=audit(1789380131.486:181296): segundos desde la época, milisegundos y después un número de serie.
wtmp/btmp/lastlog contienen segundos desde la época (más microsegundos en los registros utmp).

Convierte todo a UTC y anota cómo se obtuvo cada hora (desfase explícito, archivo de zona o año deducido).

Deduplicar y después correlacionar

En un host que ejecuta rsyslog y journald a la vez, cada línea de sshd existe dos veces. Contar ambas infla las cifras de fuerza bruta y satura la línea de tiempo. Quédate con la copia del journal (tiene campos de confianza y microsegundos) y marca la línea de texto como su duplicado, pero mantén la línea de texto disponible: si falta la copia del journal, esa diferencia es en sí misma un hallazgo.

Después, correlaciona por sesión: parejas de PID de sshd para la apertura y el cierre PAM, números de sesión de logind, ses de auditoría y registros de inicio y cierre de sesión en wtmp. Una sesión que aparece en tres fuentes pero no en wtmp es exactamente lo que deja atrás un limpiador de logs.

Hacerlo en el navegador

Linux Log Parser realiza estos pasos con los archivos que arrastras: lee logs de texto (RFC 3164 con deducción del año y conversión de zona, RFC 3339, RFC 5424, generaciones rotadas y .gz), archivos binarios del journal incluidos el modo compacto y los campos comprimidos, journalctl -o export y -o json, audit.log en formato RAW o ENRICHED, wtmp/btmp/utmp con estructuras de x86_64 y aarch64, lastlog, wtmp.db y lastlog2.db. Construye una única línea de tiempo en UTC, marca las líneas de auth.log que también contiene el journal, reconstruye las sesiones y enumera hallazgos como intentos de adivinar contraseñas seguidos de un éxito, shells de root, persistencia mediante cron y systemd, huecos en el journal y registros de wtmp puestos a cero. Todo se ejecuta localmente en WebAssembly; no se sube nada.

Siguientes pasos

Recopila los logs de un host en vivo, con una herramienta de triaje o desde una imagen de disco.
Lee auth.log y secure para SSH, sudo y cambios de cuentas.
Análisis forense del journal: formato de archivo, números de secuencia y archivos .journal~.
Análisis forense de EXECVE en auditd: auid, ses y argumentos codificados en hexadecimal.
wtmp, btmp y lastlog, incluidos wtmpdb y lastlog2.
Un caso práctico de investigación completo con el ejemplo sintético de la herramienta.

Para tablas de referencia por artefacto, las fichas de linuxforensics.app cubren el journal de systemd, auth.log y syslog, auditd, wtmp, btmp y lastlog, los logs de sudo y los artefactos de SSH.