SantiFP: Intrusión y Persistencia: Análisis de un servidor comprometido tras una elevación de privilegios

Objetivo:

Identificar, analizar y mitigar un incidente de seguridad simulado en un sistema Linux, detectando procesos anómalos en ejecución mediante ps/top, auditando los puntos de persistencia en el sistema (cron y servicios systemd) y eliminando la amenaza de forma segura.

Escenario:

Herramientas: Terminal Linux, ps, htop, crontab, systemctl, kill.
Conceptos analizados: PID, procesos en segundo plano, persistencia, tareas programadas (Cron), servicios del sistema y permisos de ejecución.
Proceso clave: Identificación del PID malicioso, rastreo del origen del binario, erradicación del mecanismo de persistencia y finalización del proceso.

Escenario Real: Actividad sospechosa en el servidor web de la empresa

El equipo de monitoreo ha detectado un consumo inusual de CPU en uno de los servidores de desarrollo fuera del horario laboral. Todo apunta a que un atacante logró comprometer un servicio vulnerable e instaló un script malicioso que se reejecuta automáticamente aunque el sistema se reinicie. Tu misión como administrador de sistemas es auditar los procesos activos, encontrar dónde se oculta el script, destruir la persistencia y matar el proceso en ejecucion.

Cuando un atacante compromete un sistema, su primer objetivo tras obtener acceso es establecer persistencia para no perder el control si el servidor se reinicia o si matas el proceso. En Linux, los métodos de persistencia más habituales son los trabajos de cron (/etc/crontab) y los servicios creados en systemd. Si te limitas a hacer un kill -9 al proceso pero no eliminas la tarea programada, el proceso malicioso volverá a aparecer en cuestión de minutos.

Instrucciones:

Fase 1: Simulación del ataque (Preparación del escenario):

Abre una terminal y crea un script que simulará ser el proceso malicioso (ej. un minador o bot):

echo -e '#!/bin/bash\nwhile true; do sleep 5; done' > /tmp/.falso_malware.sh
chmod +x /tmp/.falso_malware.sh

Ejecuta el script en segundo plano para iniciar el "incidente":
```
/tmp/.falso_malware.sh &
```
Simula la persistencia añadiendo una tarea programada en cron para que se ejecute cada minuto:
```
(crontab -l 2>/dev/null; echo "* * * * * /tmp/.falso_malware.sh") | crontab -
```

Fase 2: Identificación y rastreo del proceso sospechoso:

Inspecciona los procesos en ejecución y busca el script sospechoso:
```
ps aux | grep falso_malware
```
Apunta el PID (Process ID) del proceso detectado.
Inspecciona en qué ruta del disco se encuentra el archivo ejecutable utilizando el directorio /proc del sistema:
```
ls -l /proc/[PID_DEL_PROCESO]/exe
```

Fase 3: Erradicación de la amenaza (Persistencia + Proceso):

Regla de oro: Elimina SIEMPRE primero la persistencia antes de matar el proceso.
Edita o revisa el archivo de tareas programadas del usuario para eliminar la entrada maliciosa:
```
crontab -e
```
(Elimina la línea correspondiente a /tmp/.falso_malware.sh y guarda los cambios).
Elimina el archivo binario/script del disco:
```
rm /tmp/.falso_malware.sh
```
Finaliza definitivamente el proceso activo en memoria usando su PID:
```
kill -9 [PID_DEL_PROCESO]
```

Verificación:

Comprueba que el proceso ya no aparece en la lista activa: ps aux | grep falso_malware.
Espera 1 o 2 minutos y vuelve a listar los procesos para asegurarte de que la tarea de cron no lo ha vuelto a resucitar.

Posibles errores y resolución de problemas:

Si al intentar matar el proceso recibes el mensaje "Operation not permitted", significa que el proceso pertenece a otro usuario (o a root). En un entorno real, los malware suelen ejecutarse con permisos elevados. Deberás anteponer sudo tanto para consultar la información en /proc como para ejecutar el comando kill.

Preguntas de reflexión:

¿Por qué es un error matar el proceso con kill antes de eliminar su tarea programada en cron o systemd?
¿Qué información útil nos proporciona el sistema de archivos virtual /proc sobre un proceso en ejecución?
¿Qué diferencia existe entre enviar una señal SIGTERM (15) y una señal SIGKILL (9) a un proceso con el comando kill?
Además de crontab, ¿en qué otros directorios del sistema Linux suele un atacante ocultar scripts de inicio automático?

Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es un error matar el proceso con `kill` antes de eliminar su tarea programada en `cron` o `systemd`?

Porque si el demonio de cron o el gestor de servicios detecta que el proceso ha finalizado, volverá a ejecutar la tarea según el intervalo programado (por ejemplo, cada minuto), haciendo inútil la eliminación del proceso en memoria.

2. ¿Qué información útil nos proporciona el sistema de archivos virtual `/proc` sobre un proceso en ejecución?

El directorio /proc/[PID] contiene información en tiempo real sobre el proceso: el ejecutable real (exe), el directorio de trabajo (cwd), las variables de entorno (environ), la línea de comandos completa (cmdline) y los descriptores de archivo abiertos (fd).

3. ¿Qué diferencia existe entre enviar una señal `SIGTERM` (15) y una señal `SIGKILL` (9) a un proceso con el comando `kill`?

SIGTERM (15) solicita amablemente al proceso que finalice, permitiéndole cerrar archivos y liberar recursos de forma limpia. SIGKILL (9) es una orden directa al kernel para interrumpir el proceso de inmediato sin darle oportunidad de interceptar o ignorar la señal.

4. Además de `crontab`, ¿en qué otros directorios del sistema Linux suele un atacante ocultar scripts de inicio automático?

Suelen utilizar /etc/systemd/system/ (servicios personalizados), /etc/rc.local, /etc/init.d/, o archivos de configuración de perfil de usuario como ~/.bashrc o ~/.profile.

Páginas

Intrusión y Persistencia: Análisis de un servidor comprometido tras una elevación de privilegios