En resumen: Los procesos sospechosos en servidores Linux se reconocen por pocos rasgos: archivo de programa borrado o en /tmp, /dev/shm o un directorio web, nombre que imita un proceso del sistema, usuario inusual, conexiones de red permanentes o carga alta sin motivo. Compruebe con comandos de lectura si el archivo de programa pertenece a un paquete instalado y asegure los hallazgos antes de terminar nada.
Qué significa «sospechoso» en un proceso
En un servidor web se ejecutan cientos de procesos. La mayoría pertenecen al sistema operativo, al servidor web, a la base de datos o a PHP. Un atacante que ha podido ejecutar código mediante una vulnerabilidad como PHP2Shell intenta no llamar la atención entre ellos. Elige nombres discretos y deja programas allí donde el usuario del servidor web puede escribir.
Para la revisión ayuda conocer el estado normal. Quien sabe qué servicios deben funcionar en un servidor, bajo qué usuarios y con qué carga, reconoce las desviaciones mucho más rápido. Si falta ese conocimiento, merece la pena usar como comparación la lista de procesos de un servidor equivalente y no sospechoso.
Un rasgo aislado todavía no es una prueba. Lo decisivo es la combinación. Un proceso con el nombre de un hilo del kernel que se ejecuta bajo www-data, se inició desde /dev/shm y mantiene una conexión al extranjero es un caso claro. Cómo revisar el caso especial de una shell bajo el servidor web lo describe Señal de alerta: el servidor web inicia una shell.
Primera visión general en cinco comandos
Todos los comandos solo leen. Ejecútelos como root para ver todos los procesos y guarde las salidas en un archivo fuera del directorio web.
# 1. Todos los procesos con usuario, PID del padre, hora de inicio, CPU y línea de comandos
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Procesos cuyo archivo de programa se ha borrado
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Procesos que se ejecutan desde directorios temporales o web
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Procesos con conexiones de red
ss -tunap
# 5. Visión general de los procesos de los usuarios del servidor web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Los nombres de usuario varían según la distribución y el panel; Plesk y otros paneles suelen ejecutar PHP bajo el usuario del cliente correspondiente. Adapte la lista a su entorno.
Lea las salidas fijándose en la hora de inicio. Los procesos que se ejecutan desde el último reinicio del servidor suelen pertenecer al sistema. Los procesos iniciados en plena noche o en los días posteriores al 17 de octubre y que no encajan con ningún servicio merecen atención. Compare también el número de procesos de PHP con lo que permite la configuración de su pool; bastantes más procesos bajo un usuario del servidor web son un indicio.
Procesos sospechosos en Linux: rasgos típicos
| Rasgo | Por qué llama la atención | ¿Posible explicación inofensiva? |
|---|---|---|
| Archivo de programa «(deleted)» | Los atacantes borran archivos tras el inicio | sí, tras actualizaciones de paquetes hasta el reinicio |
Lugar de inicio /tmp, /dev/shm, carpeta de subida |
allí puede escribir cualquiera o el servidor web | rara vez |
Nombre entre corchetes como [kworker] |
imita hilos del kernel | no, si hay un archivo de programa detrás |
| Carga de CPU alta permanente sin motivo | típico de los criptomineros | sí, en trabajos por lotes o indexación |
| Proceso padre 1 y usuario del servidor web | desvinculado del servidor web, sigue funcionando por su cuenta | rara vez |
| Conexión a un destino desconocido | control o fuga de datos | sí, en actualizaciones y API |
Los hilos del kernel auténticos no tienen archivo de programa; ls -l /proc/PID/exe no devuelve en ellos ninguna ruta. Si un proceso con nombre de kernel apunta a un archivo, está camuflado. Ante una carga alta sin causa visible ayuda el artículo Criptomineros en el servidor web.
Contraprueba: ¿pertenece el archivo de programa a un paquete?
Casi todos los programas legítimos de un servidor proceden de la gestión de paquetes. Un archivo de programa que no pertenece a ningún paquete no es malicioso de forma automática, pero merece una mirada atenta.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: ¿a qué paquete pertenece el archivo?
rpm -qf "$EXE" # familia RHEL
sha256sum /proc/$PID/exe # suma de comprobación, funciona también con un archivo borrado
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # variables de entorno
Si el archivo de programa está borrado, sha256sum /proc/$PID/exe lo lee igualmente del proceso en ejecución. Esa suma de comprobación debe constar en la documentación. Una copia del archivo solo debería hacerla quien sepa guardarla de forma segura.
Límites de la revisión en el sistema en ejecución
Todos los comandos anteriores confían en el sistema que está revisando. En una intrusión corriente a través del sitio web con los derechos del usuario del servidor web, es defendible. Si un atacante ha obtenido derechos de root, puede ocultar procesos y falsear salidas. Entonces el servidor solo muestra lo que el atacante permite.
Los indicios de ello son contradicciones: carga sin proceso visible, conexiones que ve el cortafuegos pero ss no, o programas del sistema modificados. En esos casos, la revisión debe hacerse sobre una imagen asegurada. En sistemas en ejecución suele añadirse una copia de la memoria principal, porque algunos programas maliciosos existen solo allí y apenas dejan huellas en el disco. Esta copia debe hacerse antes de un reinicio y exige herramientas adecuadas y experiencia. Por qué debería hacerla antes de una reinstalación lo explica Asegurar pruebas antes de reinstalar.
No termine los procesos sospechosos como primer paso. Con frecuencia una tarea cron o un servicio los reinicia, y con el proceso desaparecen de la memoria la línea de comandos, las conexiones y el archivo de programa borrado.
Revisar los inicios automáticos y siguientes pasos
Un proceso malicioso que desapareciera tras un reinicio carecería de valor para los atacantes. Por eso, a todo hallazgo de proceso pertenece la pregunta de qué lo inicia. Además de las tareas cron, entran en juego sobre todo los servicios de systemd que un atacante con derechos de root puede crear. Llaman la atención los servicios con nombres genéricos cuyo archivo de programa está en un directorio inusual, y los archivos de unidad creados después del 17 de octubre.
# Servicios en ejecución y archivos de unidad modificados recientemente
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null
# ¿Se inyecta una biblioteca en cada proceso? Normalmente el archivo no existe.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
Una entrada en /etc/ld.so.preload es rara en servidores web normales y un fuerte indicio de manipulación con derechos de root. Cómo revisar por completo las tareas programadas lo describe Reconocer tareas cron ocultas como puerta trasera.
A continuación siguen los siguientes pasos, en este orden:
- Asegurar las salidas y las sumas de comprobación con la hora.
- Buscar persistencia: tareas cron, servicios y temporizadores de systemd, claves SSH.
- Aclarar el origen: registros desde el 20 de octubre, archivos nuevos en el directorio web.
- Aislar el servidor y planificar la limpieza o la reconstrucción.
Una visión de conjunto de todos los indicios típicos tras PHP2Shell la ofrece ¿Ya estoy comprometido?.
¿Cómo ayuda PHP SOS en concreto?
- Valorar procesos: revisamos la lista de procesos, los archivos de programa y las conexiones, y clasificamos cada hallazgo.
- Asegurar con validez forense: con el análisis forense informático aseguramos la memoria principal y los soportes de datos antes de modificar nada.
- Encontrar la persistencia: buscamos mecanismos que reinicien procesos maliciosos.
- Cerrar: limpiamos o reconstruimos y documentamos el incidente hasta su cierre.
Preguntas frecuentes
¿Cómo reconozco un proceso sospechoso en Linux?
Los rasgos típicos son un archivo de programa borrado, un lugar de inicio en /tmp o /dev/shm, un nombre que imita un proceso del sistema, un usuario inusual y conexiones de red permanentes. Los rasgos aislados son indicios; varios juntos, una sospecha seria.
¿Qué significa «(deleted)» en /proc/PID/exe?
El archivo de programa del proceso se borró después de iniciarse. Ocurre de forma legítima tras actualizaciones de paquetes, hasta que el servicio se reinicia. En procesos de carpetas temporales o bajo el usuario del servidor web, es un comportamiento típico de camuflaje.
¿Puedo fiarme de la salida de ps?
En una intrusión corriente, normalmente sí. Pero si un atacante ha obtenido derechos de root, puede manipular herramientas y salidas. Entonces es más fiable una revisión desde fuera, por ejemplo sobre una imagen asegurada.
¿Debo terminar un proceso sospechoso con kill?
No como primer paso. Asegure antes la línea de comandos, el archivo de programa, las conexiones y la hora de inicio. Un proceso terminado ya no revela nada y, con frecuencia, una tarea cron o un servicio lo reinicia de todos modos.