Cómo hacer análisis forense en Linux después de un ciberataque: logs, procesos, conexiones y evidencias

Idea central: el análisis forense en Linux debe preservar evidencia antes de modificar el sistema. Primero se documenta, luego se recolecta, después se analiza y recién entonces se contiene, erradica y recupera.

sudo mkdir -p /root/forense-$(hostname)-$(date -u +%Y%m%dT%H%M%SZ)
cd /root/forense-*

{
echo "=== INICIO DE RECOLECCION FORENSE ==="
date -u
hostname -f
whoami
id
uptime
cat /etc/os-release
uname -a
timedatectl
} | sudo tee 00_contexto_inicial.txt

# Al final de cada etapa:
sudo find . -type f -print0 | sudo xargs -0 sha256sum | sudo tee MANIFEST.sha256

Regla práctica: recolecta primero lo que se pierde al reiniciar: procesos, conexiones, sesiones, memoria, sockets, archivos temporales y logs en buffers. Luego pasa a archivos, paquetes, usuarios y persistencia.

{
  echo "=== PROCESOS COMPLETOS ==="
  ps auxwwwe

echo
echo "=== ARBOL DE PROCESOS ==="
pstree -apul

echo
echo "=== PROCESOS POR CPU ==="
ps aux --sort=-%cpu | head -n 30

echo
echo "=== PROCESOS POR MEMORIA ==="
ps aux --sort=-%mem | head -n 30
} | sudo tee 01_procesos.txt

ps auxwwwe | grep -Ei '/tmp|/var/tmp|/dev/shm|curl|wget|nc |ncat|socat|bash -i|python|perl|ruby|base64|chmod|chattr|xmrig|kworker' | tee 01_procesos_sospechosos.txt

{
  echo "=== SOCKETS TCP/UDP ==="
  ss -tunap

echo
echo "=== PUERTOS EN ESCUCHA ==="
ss -ltnup

echo
echo "=== CONEXIONES POR PROCESO ==="
lsof -nP -i

echo
echo "=== RUTAS ==="
ip route show

echo
echo "=== DNS ==="
resolvectl status 2>/dev/null || cat /etc/resolv.conf
} | sudo tee 02_red_conexiones.txt

{
  echo "=== USUARIOS CONECTADOS ==="
  who -a
  w

echo
echo "=== ULTIMOS ACCESOS ==="
last -a | head -n 100

echo
echo "=== INTENTOS FALLIDOS ==="
lastb -a | head -n 100 2>/dev/null || true

echo
echo "=== USUARIOS DEL SISTEMA ==="
getent passwd

echo
echo "=== GRUPOS ADMINISTRATIVOS ==="
getent group sudo wheel adm docker 2>/dev/null

echo
echo "=== SUDOERS ==="
sudo grep -R "^[^#]" /etc/sudoers /etc/sudoers.d/ 2>/dev/null
} | sudo tee 03_usuarios_accesos.txt

# Logs del arranque actual
sudo journalctl -b --no-pager > 04_journal_boot_actual.txt

# Logs de las últimas 24 horas

sudo journalctl --since "24 hours ago" --no-pager > 04_journal_24h.txt

# Errores y alertas

sudo journalctl -p warning..alert --since "48 hours ago" --no-pager > 04_journal_errores.txt

# Logs de SSH

sudo journalctl -u ssh --since "7 days ago" --no-pager > 04_ssh_journal.txt 2>/dev/null || 
sudo journalctl -u sshd --since "7 days ago" --no-pager > 04_sshd_journal.txt

# Exportar en JSON para análisis

sudo journalctl --since "48 hours ago" -o json > 04_journal_48h.json

sudo mkdir -p logs-copiados

# Debian / Ubuntu

sudo cp -a /var/log/auth.log* logs-copiados/ 2>/dev/null || true
sudo cp -a /var/log/syslog* logs-copiados/ 2>/dev/null || true

# RHEL / Rocky / AlmaLinux / Fedora

sudo cp -a /var/log/secure* logs-copiados/ 2>/dev/null || true
sudo cp -a /var/log/messages* logs-copiados/ 2>/dev/null || true

# Web y aplicaciones

sudo cp -a /var/log/nginx logs-copiados/ 2>/dev/null || true
sudo cp -a /var/log/apache2 logs-copiados/ 2>/dev/null || true
sudo cp -a /var/log/httpd logs-copiados/ 2>/dev/null || true
sudo cp -a /var/log/php* logs-copiados/ 2>/dev/null || true

sudo find logs-copiados -type f -print0 | sudo xargs -0 sha256sum | sudo tee logs-copiados.sha256

Patrones que debes buscar

1. SSH: intentos fallidos, acceso root, IPs desconocidas, claves aceptadas.
2. Sudo: comandos inesperados, cambios de usuario, NOPASSWD.
3. Web: rutas raras, subida de archivos, errores 500, parámetros largos, intentos de RCE.
4. Aplicación: autenticaciones anómalas, cambios de roles, errores repetidos, tokens inválidos.
5. Sistema: reinicios, cron, systemd, instalación de paquetes, errores de kernel.

# Resumen general
sudo aureport > 05_aureport_general.txt

# Logins

sudo aureport -l > 05_aureport_logins.txt

# Modificaciones de cuentas

sudo aureport -m > 05_aureport_modificaciones.txt

# Eventos anómalos

sudo aureport -n > 05_aureport_anomalias.txt

# Eventos recientes interpretados

sudo ausearch -ts recent -i > 05_ausearch_reciente.txt

# Buscar eventos de autenticación

sudo ausearch -m USER_LOGIN,USER_AUTH,USER_ACCT -i > 05_auth_audit.txt

# Buscar eventos de sudo/ejecución si están auditados

sudo ausearch -m EXECVE -i > 05_execve_audit.txt

{
  echo "=== SYSTEMD UNITS ==="
  systemctl list-unit-files --type=service --no-pager
  systemctl list-timers --all --no-pager

echo
echo "=== CRON SISTEMA ==="
ls -la /etc/cron* 2>/dev/null
cat /etc/crontab 2>/dev/null
find /etc/cron* -type f -maxdepth 2 -print -exec sed -n '1,120p' {} ; 2>/dev/null

echo
echo "=== CRON USUARIOS ==="
for u in $(cut -d: -f1 /etc/passwd); do
echo "--- $u ---"
crontab -l -u "$u" 2>/dev/null || true
done

echo
echo "=== SSH AUTHORIZED_KEYS ==="
find /root /home -path '*/.ssh/authorized_keys' -type f -print -exec sed -n '1,120p' {} ; 2>/dev/null

echo
echo "=== ARCHIVOS DE PERFIL ==="
find /root /home -maxdepth 3 \(-name ".bashrc" -o -name ".profile" -o -name ".bash_profile" -o -name ".zshrc"\) -print -exec sed -n '1,160p' {} ; 2>/dev/null
} | sudo tee 06_persistencia.txt

# Archivos modificados en las últimas 48 horas
sudo find /etc /var/www /srv /opt /tmp /var/tmp /dev/shm /home /root \
  -xdev -type f -mtime -2 -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %p\n' \
  2>/dev/null | sort > 07_archivos_modificados_48h.txt

# Archivos ejecutables sospechosos en temporales

sudo find /tmp /var/tmp /dev/shm -type f -perm /111 -ls 2>/dev/null \

> 07_ejecutables_temporales.txt

# Binarios SUID/SGID

sudo find / -xdev \(-perm -4000 -o -perm -2000\) -type f -ls 2>/dev/null \

> 07_suid_sgid.txt

sudo mkdir -p historiales

sudo find /root /home -maxdepth 3 \(\
  -name ".bash_history" -o \
  -name ".zsh_history" -o \
  -name ".mysql_history" -o \
  -name ".psql_history" -o \
  -name ".python_history" \\) -type f -print -exec cp -a --parents {} historiales/ ; 2>/dev/null

sudo find historiales -type f -print0 | sudo xargs -0 sha256sum | sudo tee 08_historiales.sha256

# Buscar patrones comunes sin ejecutar nada
sudo grep -R -Ei "wp-login|xmlrpc|admin|upload|shell|cmd=|exec|base64|eval|/etc/passwd|\.env|\.git|union select|select.*from|curl|wget" \
  /var/log/nginx /var/log/apache2 /var/log/httpd 2>/dev/null \
  > 09_patrones_logs_web.txt

# Buscar archivos PHP recientes o sospechosos

sudo find /var/www /srv -type f \(-name "*.php" -o -name "*.phtml" -o -name "*.phar"\) 
-mtime -15 -printf '%TY-%Tm-%Td %TH:%TM:%TS %u %g %m %p\n' 2>/dev/null \

> 09_php_recientes.txt

# Debian / Ubuntu
dpkg -l > 10_dpkg_paquetes.txt
grep " install " /var/log/dpkg.log* 2>/dev/null > 10_dpkg_instalaciones.txt
sudo debsums -s > 10_debsums_sospechas.txt 2>/dev/null || true

# RHEL / Rocky / AlmaLinux / Fedora

rpm -qa --last > 10_rpm_paquetes_ultimo.txt
sudo rpm -Va > 10_rpm_verificacion.txt 2>/dev/null || true

{
  echo "=== DOCKER PS ==="
  docker ps -a 2>/dev/null || true

echo
echo "=== DOCKER IMAGES ==="
docker images 2>/dev/null || true

echo
echo "=== DOCKER NETWORKS ==="
docker network ls 2>/dev/null || true

echo
echo "=== DOCKER VOLUMES ==="
docker volume ls 2>/dev/null || true

echo
echo "=== CONTAINERD ==="
ctr containers list 2>/dev/null || true
} | sudo tee 11_contenedores.txt

Fecha/Hora UTC | Fuente | Evento | IP/Usuario/Proceso | Evidencia | Interpretación

2026-09-08 02:14:31 | nginx access.log | POST /upload.php | 198.51.100.23 | línea 14421 | Posible subida inicial
2026-09-08 02:15:02 | filesystem | shell.php creado | www-data | hash SHA256 | Webshell probable
2026-09-08 02:16:40 | ss/lsof | conexión saliente | php-fpm → 203.0.113.50:4444 | captura ss | Shell reversa probable
2026-09-08 02:19:10 | auth.log | sudo fallido | www-data | auth.log | Intento de escalamiento

No hagas esto sin preservar evidencia

1. Reiniciar el servidor.
2. Borrar webshells, scripts o binarios sospechosos.
3. Limpiar logs.
4. Actualizar paquetes masivamente.
5. Reinstalar sin snapshot o imagen previa.
6. Cambiar contraseñas sin registrar qué cuentas estaban comprometidas.
7. Ejecutar herramientas de limpieza automáticas sin saber qué eliminan.

Recuperación mínima recomendada

1. Preservar evidencia: logs, archivos, snapshots, hashes y línea de tiempo.
2. Identificar vector: vulnerabilidad, credencial, webshell, plugin, SSH o dependencia.
3. Construir servidor limpio: imagen confiable y paquetes actualizados.
4. Restaurar datos verificados: evitar traer de vuelta malware o persistencia.
5. Rotar secretos: contraseñas, tokens, claves SSH, API keys y certificados expuestos.
6. Endurecer: MFA, firewall, SELinux/AppArmor, backups, monitoreo y mínimos privilegios.
7. Validar: escaneo, revisión de logs, pruebas funcionales y monitoreo posterior.

Checklist operativo

1. Registrar contexto: fecha UTC, responsable, servidor, IP, sistema y kernel.
2. Preservar evidencia volátil: procesos, conexiones, sesiones y sockets.
3. Copiar logs: journalctl, auth.log, secure, syslog, web, aplicación y auditd.
4. Revisar usuarios: cuentas nuevas, sudoers, grupos, claves SSH y accesos.
5. Buscar persistencia: cron, systemd, timers, perfiles, SUID y scripts ocultos.
6. Analizar archivos recientes: /tmp, /dev/shm, /var/www, /etc, /home y /root.
7. Revisar red: ss, lsof, rutas, DNS, puertos abiertos y conexiones salientes.
8. Calcular hashes: evidencia, webshells, binarios sospechosos y logs copiados.
9. Construir línea de tiempo: correlacionar evento, fuente, hora y evidencia.
10. Definir alcance: datos, credenciales, servidores, nube, usuarios y movimiento lateral.
11. Contener: aislar sin destruir evidencia.
12. Recuperar: reconstruir limpio, parchear, rotar secretos y validar.
13. Informar: hallazgos, impacto, acciones y recomendaciones.

• Reiniciar el servidor antes de capturar procesos y conexiones.
• Borrar archivos sospechosos antes de copiarlos y calcular hashes.
• Confiar únicamente en el sistema comprometido sin considerar herramientas alteradas.
• No registrar hora UTC ni zona horaria de los logs.
• No revisar cron, systemd, claves SSH y usuarios nuevos.
• Mirar solo logs web y olvidar logs de autenticación, sudo y sistema.
• No revisar conexiones salientes ni posibles canales de exfiltración.
• Restaurar backups sin verificar si contienen persistencia o malware.
• No rotar secretos después de indicios de compromiso.
• No generar informe con evidencia, línea de tiempo y recomendaciones.

¿Debo apagar el servidor después de detectar un ataque?

Depende del riesgo. Si el atacante sigue activo y hay peligro de daño mayor, puede ser necesario aislarlo de red. Pero antes de apagar o reiniciar conviene capturar evidencia volátil, como procesos, conexiones, sesiones y logs recientes.

¿Qué evidencia se pierde al reiniciar Linux?

Procesos activos, conexiones de red, memoria, sesiones, sockets, archivos temporales no persistentes y parte del contexto operativo. Por eso la recolección inicial debe priorizar evidencia volátil.

¿journalctl sirve para análisis forense?

Sí. journalctl permite revisar logs por unidad, arranque y rango de tiempo, además de exportar en formatos como JSON. Es una fuente clave en sistemas con systemd.

¿auditd siempre tendrá registros útiles?

Solo si estaba habilitado y configurado antes o durante el evento. auditd escribe registros de auditoría en disco y sus logs se consultan con ausearch o aureport, pero no puede reconstruir eventos que nunca fueron auditados.

¿Cuándo conviene reconstruir el servidor?

Si hubo compromiso root, persistencia desconocida, malware activo, alteración de binarios o dudas sobre integridad del sistema, lo más seguro suele ser reconstruir desde imagen limpia, restaurar datos verificados y rotar secretos.

• Cómo saber si tu Linux está bien protegido: 30 comprobaciones de seguridad que puedes realizar ahora mismo
• Cómo proteger un servidor Linux frente a vulnerabilidades Zero-Day cuando todavía no existe un parche
• Cómo saber si tu Linux necesita una actualización urgente: kernel, paquetes, firmware y vulnerabilidades críticas
• Cómo crear un sistema de gestión de vulnerabilidades con software libre: inventario, CVE, prioridades, parches y seguimiento
• Cómo proteger un servidor Linux contra ataques DDoS: configuración, monitoreo y mitigación
• Guía completa de SELinux y AppArmor: cómo proteger aplicaciones y servicios sin complicarte la vida

Cierre editorial

Un servidor Linux atacado no debe tratarse como una máquina sucia que solo necesita limpieza. Debe tratarse como una escena técnica que cuenta una historia: procesos, conexiones, logs, usuarios y archivos muestran el camino del atacante. Quien preserva evidencia entiende el incidente; quien borra primero, pierde la oportunidad de aprender y proteger mejor.