systemd, cron y journald — cómo vuelve un intruso después del reinicio

systemd arranca y vigila casi todo lo que corre en un Linux moderno. Dos tipos de unidad interesan al turno. La unidad de servicio (.service) describe un programa que se ejecuta y se mantiene; la unidad de temporizador (.timer) describe cuándo se dispara un servicio, con una precisión parecida a la de cron pero integrada en el sistema y con su propio registro.

Un temporizador es un buen sitio para esconderse por dos motivos. Primero, porque la lista de unidades de un servidor normal tiene decenas de entradas y casi nadie la revisa entera. Segundo, porque un temporizador que dispara cada pocos minutos reconstruye el acceso una y otra vez sin dejar un proceso permanente que llame la atención en la lista de procesos. En ATT&CK es T1053.006.

El dato que lo delata no es el nombre —se elige para parecer de la casa— sino el origen: una unidad legítima llega instalada por un paquete o por el despliegue de TI y aparece en decenas de equipos; la otra existe en un solo servidor y no figura en ningún catálogo.

Antes de los temporizadores estaba cron, y sigue en todas partes. Sus tareas viven en sitios distintos y conviene saberlos porque cada uno se lee de una manera: los archivos de /etc/cron.d/ y los directorios /etc/cron.daily/ y similares son del sistema y suelen estar gestionados por paquetes; la tabla personal de cada cuenta (crontab -l, guardada bajo /var/spool/cron/) es del usuario y es exactamente donde se mira cuando se sospecha de una cuenta concreta.

Una línea de cron trae la planificación y el comando. Lo que levanta la ceja es la combinación: una cuenta de servicio o de usuario normal ejecutando algo cada pocos minutos desde un directorio temporal o desde su propio perfil. Ningún trabajo legítimo de una empresa vive en /tmp: esa carpeta se vacía, no tiene dueño claro y cualquiera escribe en ella, que es justo por lo que se usa.

systemd trae su propio almacén de registros, journald, que guarda en formato binario y se consulta con journalctl. Tiene ventajas reales —índices, filtros por unidad, por prioridad y por ventana de tiempo— y una característica que un analista debe tener presente: el diario es local y recortable. Su tamaño se limita por configuración y existen operaciones de mantenimiento que borran lo más antiguo hasta dejarlo en el tamaño pedido.

Eso significa dos cosas. Una, que el diario de una máquina comprometida puede estar incompleto por razones perfectamente inocentes. Y dos, que un recorte a destiempo —justo después de la actividad sospechosa, lanzado desde una sesión interactiva— es en sí mismo un hallazgo: borrar el rastro es una técnica, no un accidente. De ahí la regla que sostiene toda esta parte del oficio: los registros se envían fuera de la máquina en el momento en que se escriben, porque el único registro que un intruso no puede tocar es el que ya está en otro sitio.

En la consola tienes las unidades y las tareas programadas de los servidores Linux de Delta Cargo, con su procedencia, más el diario del bastión de esa madrugada. Entre las unidades del catálogo de TI hay una que se habilitó de madrugada en un solo equipo y que vuelve a ejecutarse cada media hora. Encuentra cómo se llama.