Investigando un servidor Linux comprometido, ¿dónde buscas la persistencia del atacante?
Respuesta breve
La persistencia en Linux se esconde en las rutas de ejecución programada y de arranque: cron y timers/unidades de systemd, claves añadidas en authorized_keys SSH, archivos rc del shell y scripts de perfil modificados, y binarios de servicio o bibliotecas precargadas troyanizados. Revísalos sistemáticamente. El historial del navegador y la configuración del fondo de pantalla no son mecanismos de persistencia, y reiniciar no eliminará nada que se restablezca en el arranque — solo lo relanza. El propósito de la persistencia es sobrevivir a los reinicios, así que un reinicio no demuestra nada.
La persistencia es la forma en que un atacante mantiene el acceso tras el punto de entrada inicial — y en Linux reside en un conjunto bien conocido de lugares: todo lo que el sistema ejecuta automáticamente según una programación, en el arranque o en el inicio de sesión. Un respondedor competente recorre esa lista metódicamente en lugar de perseguir lo más visible.
Dónde buscar realmente
- Ejecución programada: los
crontabde usuario y de sistema,/etc/cron.*, y sobre todo los timers y unidades de systemd (systemctl list-timers, archivos de unidad en/etc/systemd/systemy~/.config/systemd/user). - Acceso SSH: claves añadidas en
~/.ssh/authorized_keyspara cada usuario, incluidas las cuentas de servicio; una clave de atacante aquí es una puerta trasera discreta y duradera. - Archivos de inicio del shell:
~/.bashrc,~/.bash_profile,~/.profile,/etc/profile.d/*— el código depositado aquí se ejecuta en cada inicio de sesión interactivo. - Binarios y bibliotecas troyanizados: binarios de servicio modificados, secuestros mediante
LD_PRELOAD//etc/ld.so.preload, y objetos compartidos manipulados que se cargan en procesos legítimos.
Coteja estos elementos con una línea base confiable, las fechas MAC de los archivos y las comprobaciones de integridad del gestor de paquetes.
Por qué los distractores son incorrectos
- El historial del navegador es actividad del usuario, no un mecanismo de persistencia. Puede aportar contexto, pero no relanzará el código del atacante.
- La configuración del fondo de pantalla es cosmética e irrelevante para la persistencia de un servidor.
- «Un reinicio elimina la persistencia» es exactamente lo contrario de la realidad. La propiedad que define la persistencia es que sobrevive a un reinicio — cron, systemd y los archivos rc se vuelven a disparar en el arranque o el inicio de sesión. Reiniciar solo relanza el código malicioso y puede destruir pruebas volátiles en el proceso.
Qué está evaluando el entrevistador
Si tienes un mapa mental real de las superficies de autoarranque de Linux y abordas un host comprometido de forma sistemática, en lugar de hurgar en el primer artefacto gráfico a mano. El distractor del reinicio prueba específicamente si entiendes qué significa realmente «persistencia».
Posibles preguntas de seguimiento
- ¿Cómo daría LD_PRELOAD o un /etc/ld.so.preload alterado al atacante persistencia a nivel de biblioteca?
- ¿Qué directorios de systemd compararías con una línea base confiable, y por qué?
- ¿Cómo distingues un binario de servicio troyanizado de uno actualizado legítimamente?