Archivos recientes, paquetes y marcas de tiempo

Un archivo en ext4 guarda varias marcas, y stat las muestra. Modify (mtime) es cuándo cambió el contenido; Access (atime) cuándo se leyó por última vez, aunque con la opción habitual relatime solo se actualiza de vez en cuando y no sirve para saber cada lectura; Change (ctime) es cuándo cambió el inodo, es decir, el contenido o los metadatos, como el dueño, los permisos o el nombre; y Birth es cuándo se creó el archivo.

La diferencia clave para quien investiga: touch puede poner a mano Modify y Access, pero no existe forma corriente de fijar Change, porque la fija el núcleo cada vez que el inodo cambia. Si alguien retrasa Modify, el propio acto de retrasarlo deja Change con la hora real de la manipulación.

En el stat de un archivo sospechoso las cuatro marcas cuentan una historia cuando se leen juntas. Si Birth y Change están en la misma noche, y Modify está años atrás y con una hora redonda, el contenido «es» antiguo solo en apariencia: la fecha vieja la escribió alguien, no el tiempo. La diferencia entre Birth y Change, además, indica cuándo se manipuló el archivo después de crearlo.

Para el informe, lo valioso es dar la hora que el atacante no pudo falsear, con su fuente y su marca: «Change, según stat, a las HH:MM:SS UTC».

Abre stat-archivos.txt y lee el archivo oculto de /var/tmp.

Un listado de «archivos cambiados desde tal hora» depende de qué marca se filtre. Con find se puede filtrar por Modify o por Change. Todo cambio de contenido cambia también Change, así que el listado por Change contiene al de Modify y, además, los archivos cuya fecha de modificación fue manipulada.

Es una comprobación barata y muy útil: se hacen los dos listados y se restan. Lo que sale en el de Change y no en el de Modify merece mirarse con lupa.

Abre find-por-mtime.txt y find-por-ctime.txt.

Los paquetes instalados dejan dos registros: /var/log/dpkg.log anota cada instalación y actualización con su hora, y /var/log/apt/history.log agrupa lo que hizo cada orden de apt y, cuando se lanza con sudo, suele guardar quién la pidió. La empresa, por su parte, tiene una ventana de cambios aprobada. Una instalación dentro de la ventana, pedida por su administrador, es operación normal; una fuera de ella no tiene cambio aprobado.

Un paquete nuevo no es malo por sí mismo, pero cada herramienta añadida a un servidor comprometido amplía lo que se pudo hacer y debe constar en el informe.

Cruza dpkg.log, apt-history.log y registro-de-cambios.txt.

Hay unidades y un paquete creados por root en una franja donde el único acceso de entrada fue svc-tienda, una cuenta que a las 02:09 recibió un rechazo de sudo, y el tramo de auth.log donde estarían los registros de sudo de esa franja fue recortado. La evidencia muestra los efectos, no la vía: no dice cómo se obtuvo root.

Un informe de respuesta a incidentes separa lo demostrado de lo supuesto. «Se obtuvo root con una cuenta de servicio con sudo excesivo» es una hipótesis válida para investigar; escrita como hecho, sin evidencia, es un hallazgo falso que otro tendrá que desmentir.