Qué son los logs y por qué son la prueba reina en casos técnicos
Un log es un registro automático que genera un sistema informático cada vez que ocurre un evento: una conexión, una consulta a la base de datos, un error, un cambio de permisos, un envío de email. Los logs son el equivalente digital de las cámaras de seguridad en un edificio: no mienten, no interpretan, solo registran lo que ocurre.
En un procedimiento judicial donde se discute «quién hizo qué y cuándo» en un sistema informático, los logs son la evidencia más objetiva disponible. A diferencia de los testimonios (subjetivos) o los documentos (que pueden falsificarse), los logs se generan automáticamente por el sistema y contienen información de marca temporal, identidad y acción que permite reconstruir la cronología de los hechos con precisión de segundos.
El problema es que los logs, en su formato original, son ininteligibles para un juez, un abogado o un jurado. Miles de líneas de texto técnico, códigos de estado HTTP, direcciones IP y timestamps en formatos diversos. El trabajo del perito informático es convertir esa materia prima en una cronología clara, verificable y comprensible para quien debe valorar la prueba.
Tipos de logs relevantes para un procedimiento judicial
Logs de sistema operativo
Registros de arranque, apagado, inicio y cierre de sesión, instalación de software y errores del kernel. En Windows: Event Log (Security, System, Application). En Linux: syslog, auth.log, kern.log. Permiten determinar cuándo se usó un equipo y quién inició sesión.
Logs de aplicación
Cada aplicación (ERP, CRM, gestión documental, correo) genera sus propios logs. Registran acciones del usuario dentro de la aplicación: qué registros consultó, qué datos modificó, qué exportó. Son cruciales en casos de competencia desleal o robo de información.
Logs de acceso (web/SSH/RDP)
Registran cada conexión al servidor: IP de origen, protocolo utilizado, credenciales empleadas, resultado (éxito/fallo). Apache y Nginx mantienen access.log y error.log. Los servidores SSH registran cada intento de conexión con IP y usuario. Fundamentales para probar accesos no autorizados.
Logs de base de datos
PostgreSQL, MySQL, Oracle y SQL Server pueden registrar cada consulta ejecutada (query log), cambios de permisos, creación/eliminación de tablas y exportaciones masivas de datos. Especialmente relevantes en casos de acceso indebido a BBDD.
Logs de red (firewall/proxy/IDS)
Registran todo el tráfico de red: conexiones permitidas y denegadas, URLs visitadas, volumen de datos transferidos. Permiten detectar exfiltración de datos, conexiones a servidores maliciosos y patrones de tráfico anómalos.
Logs de cloud (auditoría)
AWS CloudTrail, Azure Activity Log, GCP Cloud Audit Logs. Registran toda operación realizada en la infraestructura cloud: creación y destrucción de recursos, cambios de permisos IAM, accesos a buckets de almacenamiento. Imprescindibles en entornos híbridos o full-cloud.
Normalización temporal: por qué NTP y la zona horaria lo cambian todo
El problema más subestimado en el análisis de logs es la inconsistencia temporal. Un servidor puede registrar en UTC, otro en horario local (CET/CEST), un firewall en epoch Unix y una aplicación en un formato de fecha propio. Si no se normaliza todo a una referencia temporal común antes de correlacionar, la cronología resultante puede tener errores de horas, lo que invalida las conclusiones.
El protocolo NTP (Network Time Protocol) sincroniza los relojes de los sistemas con un servidor de referencia. Si los equipos involucrados en el incidente no estaban sincronizados vía NTP, los timestamps de sus logs pueden divergir minutos o incluso horas. El perito debe verificar la configuración NTP de cada sistema y documentar el desfase, si existe.
En el informe pericial, la normalización temporal se explica al juez con un ejemplo sencillo: «El servidor A registra las 14:00 UTC, que equivale a las 16:00 hora local de Mallorca en horario de verano (CEST). El servidor B registra directamente las 16:00 CEST. Ambos registran el mismo momento, pero con formatos distintos. Se ha normalizado toda la cronología a hora local de Mallorca para facilitar la lectura.» Sin esta explicación, un abogado podría cuestionar discrepancias horarias aparentes que en realidad no existen.
Correlación de eventos: construir la cronología del incidente
La correlación consiste en cruzar los eventos registrados en diferentes fuentes (sistema operativo, aplicación, firewall, base de datos) para construir una narrativa coherente de lo ocurrido. El objetivo es responder a la pregunta central del caso: ¿quién hizo qué, desde dónde, cuándo y con qué resultado?
Por ejemplo, en un caso de acceso indebido, la correlación podría mostrar: «A las 23:47 se registra un login exitoso desde la IP 82.XX.XX.XX con las credenciales del usuario jperez. A las 23:48, el log de la base de datos registra una consulta SELECT * FROM clientes WHERE facturación > 100000 desde la misma sesión. A las 23:52, el firewall registra una conexión saliente al puerto 443 hacia un servidor externo con 14 MB de datos transferidos. A las 23:54, el usuario cierra sesión.» Esta secuencia, documentada con precisión temporal y fuentes verificables, es prueba de exfiltración de datos.
La presentación de la cronología correlacionada suele hacerse en formato de timeline (línea temporal) con columnas para la hora, el sistema de origen, el usuario, la acción y la relevancia para el caso. Este formato visual permite que el juez siga la narrativa técnica sin necesidad de leer logs en crudo.
Señales de manipulación de logs
Uno de los aspectos que un perito revisa sistemáticamente es si los logs han sido alterados deliberadamente. Las señales de manipulación más frecuentes son:
Gaps temporales inexplicables
Un servidor que registra eventos cada pocos segundos y de repente tiene un hueco de 4 horas sin ningún registro. Podría ser un reinicio legítimo (verificable con otros logs) o un borrado selectivo.
Timestamps fuera de secuencia
Entradas de log que rompen el orden cronológico natural (un evento a las 15:00 seguido de uno a las 14:30). Puede indicar inserción manual de registros fabricados.
Discrepancia entre fuentes
El firewall registra una conexión que no aparece en el log del servidor, o viceversa. Si un sistema registró el evento y otro no, hay que investigar la razón. Si se borraron en un sistema pero no en el otro, es evidencia de manipulación selectiva.
Truncamiento abrupto del archivo
Un archivo de log que termina a mitad de línea o cuyo tamaño cambia radicalmente de un día a otro (verificable comparando con backups previos).
Herramientas de análisis y visualización admisibles
Las herramientas que utiliza el perito para analizar logs deben ser auditables y reconocidas en la comunidad forense. No se trata de usar la herramienta «más cara», sino la más adecuada al caso y cuyo funcionamiento pueda explicarse al tribunal si se cuestiona la metodología.
Entre las más utilizadas están: herramientas de línea de comandos estándar (grep, awk, sort, uniq) para filtrado y búsqueda; herramientas SIEM para correlación a gran escala (Splunk, ELK Stack); suites forenses que integran análisis de logs (Autopsy, X-Ways); y herramientas especializadas de timeline (log2timeline/Plaso). Para la visualización, se utilizan timelines gráficas que permiten presentar la secuencia de eventos de forma comprensible.
Lo que un contra-peritaje cuestiona habitualmente es la falta de documentación de las herramientas: versión utilizada, parámetros aplicados, criterios de filtrado. Un informe que dice «se analizaron los logs y se encontró…» sin explicar cómo se hizo el análisis es vulnerable a impugnación.
Cómo presentar una timeline de logs ante un juez
La clave es la claridad sin pérdida de rigor. El juez no necesita ver 50.000 líneas de log; necesita entender la secuencia de hechos relevantes, saber que provienen de fuentes fiables y que no han sido alteradas. La presentación ideal combina tres elementos:
Primero, una tabla cronológica resumida en el cuerpo del informe con las columnas: hora normalizada, sistema de origen, usuario/IP, acción realizada y relevancia para el caso. Cada fila referencia el registro original en los anexos.
Segundo, un diagrama de timeline visual (línea temporal gráfica) que permita al juez y los abogados ver la secuencia completa en una página y apreciar las relaciones causales entre eventos.
Tercero, los anexos con los logs originales, preservados con hash documentado, donde cada registro citado en el cuerpo del informe pueda ser localizado y verificado por otro perito si se solicita un contra-peritaje. La trazabilidad entre la conclusión del informe y el dato original es lo que le da solidez probatoria.
¿Necesitas analizar logs para un caso judicial?
Convierto registros técnicos en cronologías claras y defendibles ante cualquier tribunal de Mallorca.
Preguntas frecuentes
No existe un periodo legal único para todos los sectores. La LSSI obliga a los prestadores de servicios de la sociedad de la información a conservar datos de conexión durante 12 meses. En la práctica, muchas empresas mantienen logs entre 30 y 90 días por defecto en sus sistemas, y los pierden por rotación automática sin ser conscientes. Para empresas que puedan verse involucradas en litigios, se recomienda configurar una retención mínima de 12 meses en logs de acceso y autenticación.
Técnicamente, sí: un usuario con privilegios de administrador (root) puede modificar, borrar o insertar registros en los archivos de log. Sin embargo, la falsificación deja huellas detectables: inconsistencias en los timestamps, gaps temporales inexplicables, discrepancias con otros sistemas que registran los mismos eventos (firewall, IDS, cloud) y alteraciones en los metadatos del propio archivo de log. Un perito experimentado busca estas señales sistemáticamente.
Si la empresa destruyó los logs cuando ya existía obligación de conservarlos (por ejemplo, tras recibir un burofax o una demanda), podría incurrir en destrucción de prueba, lo que en el procedimiento civil puede dar lugar a presunciones desfavorables. En el ámbito penal, podría constituir un delito de obstrucción a la justicia. El perito puede documentar la ausencia de logs, las políticas de retención configuradas y si el borrado fue rutinario (por rotación automática) o deliberado.
Sí, los logs de proveedores cloud (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) son evidencia válida en procedimientos judiciales españoles. Su valor probatorio depende de cómo se adquieran y presenten: deben exportarse con garantías de integridad (hash), documentarse su procedencia y preservarse la cadena de custodia. El hecho de que estén en un servidor de un tercero (el proveedor cloud) no les resta validez, pero sí requiere explicar al juez su naturaleza y fiabilidad.
Los formatos más habituales en informática forense son: syslog (estándar en sistemas Unix/Linux), Event Log de Windows (formato EVTX), logs de aplicación en texto plano o JSON, logs de bases de datos (PostgreSQL, MySQL, Oracle), logs de servicios web (Apache, Nginx) y los formatos propietarios de soluciones de seguridad (firewalls, SIEM, EDR). Todos son válidos como evidencia si se preservan íntegros y se documentan correctamente.
Depende de cómo y cuándo se eliminaron. Si los logs se borraron mediante rotación automática reciente, es posible que aún existan en el espacio no asignado del disco y se puedan recuperar mediante técnicas de carving. Si el disco ha tenido actividad significativa posterior, las posibilidades disminuyen. En entornos cloud, una vez que los logs se purgan del servicio, la recuperación depende de si existían copias en un SIEM, en backups o en un bucket de almacenamiento secundario.
La integridad de un log se demuestra mediante hashes (calculados en el momento de la adquisición y verificados antes del análisis), firmas digitales del servidor de logs (algunos SIEM firman cada entrada), correlación con fuentes independientes (el mismo evento registrado en el firewall, el IDS y el servidor de aplicación) y el análisis de consistencia interna (secuencias temporales lógicas, sin gaps ni duplicados injustificados). Un perito documenta todas estas verificaciones en el informe.
El log de acceso registra las conexiones al sistema: quién se conectó, desde qué IP, a qué hora y con qué protocolo (SSH, RDP, HTTP). El log de auditoría va más allá y registra las acciones realizadas dentro del sistema: qué archivos se abrieron, qué consultas se ejecutaron en la base de datos, qué permisos se cambiaron, qué datos se exportaron. Para un juicio, el log de auditoría suele ser más valioso porque permite reconstruir no solo quién entró, sino qué hizo.