Son las ocho y media de la mañana y el servidor de nóminas de una empresa
pequeña muestra actividad que nadie reconoce. No hay un SIEM, no hay un
equipo de guardia: hay una responsable de sistemas, una cámara en la sala de
administración, un auth.log y la reunión con dirección dentro de unas
horas. Así empiezan de verdad la mayoría de incidentes en una pyme, y no con
una alerta roja en un panel.
Lo difícil en esa situación no es teclear grep. Es saber qué pregunta
hacerle a cada evidencia, no fiarse de la primera hora que aparece en
pantalla, no borrar la prueba al limpiar el sistema y no echar del servidor a
quien está trabajando. El caso Montseny es eso, en cuatro capítulos: vídeo,
deducción y un terminal forense con registros que se leen como los de un
servidor real.
A quién va dirigido
| Formación | Curso de especialización en Ciberseguridad en entornos de las TI |
| Módulo | 5021 · Incidentes de ciberseguridad |
| RA principal | RA3 · Investiga incidentes de ciberseguridad analizando los riesgos implicados y definiendo las posibles medidas a adoptar |
| CA que trabaja | 3.2 análisis de evidencias · 3.3 investigación del incidente · 3.5 primeras medidas de contención |
| CA que roza | 3.1 (las evidencias llegan como copia de solo lectura y el caso insiste en conservarlas, pero no se practica la adquisición) · RA2 2.3 (detección con elementos de seguridad física: la cámara y el puesto de trabajo) y 2.5 (documentación y seguimiento) · RA4 4.5 (lecciones aprendidas en el informe) |
| Duración | unas 4 horas, en una o dos sesiones |
| Formato | en equipo, por capítulos, con informe final puntuado |
| Idiomas | ES · CA · EN (la voz de los vídeos es en castellano; los subtítulos van en los tres) |
La teoría
El ciclo de vida de un incidente
La referencia que casi todo el mundo usa para ordenar una respuesta es la guía NIST SP 800-61 (Computer Security Incident Handling Guide). En su revisión 2 (2012) describe cuatro fases que se recorren en bucle:
| Fase | Pregunta que contesta | En el caso |
|---|---|---|
| Preparación | ¿Qué tenemos listo antes de que pase? | lo que faltaba: relojes sincronizados, MFA, mesas limpias |
| Detección y análisis | ¿Qué ha pasado, cuándo, desde dónde y con qué alcance? | capítulos 1 y 2 |
| Contención, erradicación y recuperación | ¿Cómo paro el daño, quito lo que dejó el atacante y vuelvo a la normalidad? | capítulos 2, 3 y 4 |
| Actividad posterior | ¿Qué aprendemos para que no se repita? | el informe final |
La revisión 3, publicada en 2024, reorganiza el mismo contenido sobre las funciones del NIST Cybersecurity Framework 2.0 (gobernar, identificar, proteger, detectar, responder, recuperar). El fondo no cambia: la respuesta no empieza con el incidente ni termina al cerrarlo.
Una idea de ese ciclo que el caso hace sentir: contener no es erradicar. Bloquear la salida de datos detiene la hemorragia, pero si el atacante dejó una puerta trasera va a volver. Y si nadie cambia la credencial comprometida, también.
Evidencia y cadena de custodia
Una evidencia digital solo sirve si se puede demostrar que no ha cambiado desde que se recogió. Para eso:
- Se trabaja sobre copias, nunca sobre el original. En el caso, el terminal del primer capítulo es una copia de solo lectura, y en el tercero se recuerda que antes de borrar algo se guarda una copia como evidencia.
- Se calcula un resumen criptográfico (
sha256sum) en el momento de la adquisición y se vuelve a calcular en cada traspaso. Si coincide, el fichero es el mismo. - Se documenta la cadena de custodia: qué se recogió, de qué equipo, quién, cuándo, con qué herramienta, dónde se guarda y por qué manos ha pasado. Un hueco en esa lista es un argumento para la otra parte.
- Se respeta el orden de volatilidad. La RFC 3227 (Guidelines for Evidence Collection and Archiving) pide recoger primero lo que desaparece antes: registros de la CPU, memoria, conexiones y procesos en curso, y después el disco y las copias de seguridad. Apagar el servidor «para que no siga entrando» borra justamente lo más volátil.
Las normas de referencia son la ISO/IEC 27037 (identificación, recogida, adquisición y preservación de evidencia digital) y, en España, la UNE 71506 sobre metodología de análisis forense de evidencias electrónicas.
Y una regla que en el caso se nota: una cuenta comprometida se bloquea, no se borra. Borrarla elimina su directorio, sus claves y su historial, que son parte de la prueba.
Leer los registros de un Linux
Un servidor Debian o Ubuntu guarda la historia de un acceso en varios sitios que no dicen lo mismo:
| Fuente | Qué contiene | Cómo se lee | Cuidado con |
|---|---|---|---|
/var/log/auth.log | autenticación: sshd, sudo, PAM, systemd-logind | grep, awk, less | en RHEL y derivados se llama /var/log/secure |
/var/log/wtmp | sesiones abiertas y cerradas, reinicios | last | es binario: cat no sirve |
/var/log/btmp | intentos fallidos | lastb (con sudo) | puede no existir o rotarse |
/run/utmp | quién está dentro ahora | who, w | se vacía al reiniciar |
~/.bash_history | órdenes escritas en Bash | cat | se escribe al cerrar la sesión, sin hora salvo HISTTIMEFORMAT, y se desactiva con una línea |
/etc/crontab, /etc/cron.d/, /var/spool/cron/crontabs/ | tareas programadas del sistema y de cada usuario | ls -l, cat, crontab -l -u | la ejecución queda en syslog como CRON[pid]: (usuario) CMD (…) |
~/.ssh/authorized_keys | claves que pueden entrar sin contraseña | cat | cualquier línea es una llave más |
Las líneas de sshd que importan tienen formas fijas: Accepted password
for USUARIO from IP port N ssh2, Accepted publickey for …, Failed
password for … e Invalid user … from …. Dos lecturas que se confunden a
menudo:
- Muchos fallos no prueban que alguien entrara, y un acceso correcto sin fallos previos no prueba que fuera legítimo. Cualquier SSH expuesto a internet recibe intentos a todas horas: son ruido de fondo hasta que se demuestre lo contrario.
- La ausencia de rastro no es inocencia. Un historial vacío puede significar que no se hizo nada o que alguien ejecutó
unset HISTFILE.
Persistencia: lo que se queda dentro
Quien ha entrado quiere poder volver. Los sitios clásicos en Linux son
pocos: tareas de cron, temporizadores y servicios de systemd,
claves SSH añadidas a authorized_keys, ficheros de arranque del shell
(.bashrc, .profile), usuarios nuevos o con UID 0, y binarios con SUID que
no estaban.
Lo que delata la persistencia es casi siempre la regularidad: algo que
ocurre cada N minutos exactos, al mismo segundo, en un servidor donde las
personas no trabajan con esa precisión. Y lo que la delata en disco es lo
que no encaja con sus vecinos: una fecha de modificación distinta, un
nombre que imita a otro legítimo. Ojo: el mtime que enseña ls -l se
cambia con touch, así que es un indicio, no una prueba.
Al erradicar se falla de dos maneras: dejando la puerta trasera o llevándose por delante algo legítimo que se le parecía.
La línea temporal, y los relojes que mienten
La línea temporal es la columna vertebral del informe: cada evento, con su hora normalizada a una sola referencia (normalmente UTC, anotando el desfase aplicado a cada fuente), su fuente y su grado de certeza. «Sesión abierta a las HH:MM desde tal IP» es un hecho; «copió las nóminas» puede ser una inferencia, y el informe tiene que distinguirlos.
El formato clásico de syslog (Mar 3 12:05:09) no lleva ni año ni zona
horaria: la hora es la local del servidor y hay que saber cuál era. Las
distribuciones recientes escriben ISO 8601 con el desfase incluido, y eso
ahorra disgustos. En la España peninsular el desfase cambia dos veces al
año: UTC+1 en invierno y UTC+2 en verano, con el cambio el último domingo de
marzo y el último de octubre. Un equipo que no se actualiza tras el cambio
de hora va exactamente una hora desviado, y un equipo sin NTP deriva
segundos o minutos cada semana.
Cuando dos fuentes no coinciden, la pregunta no es cuál tiene razón, sino cuál está sincronizada y cuánto se desvía la otra. Se calcula el desfase con un evento que aparezca en las dos y se aplica a todo lo demás. Por eso NTP en todos los equipos —servidores, pero también grabadores de cámaras, cortafuegos y controladores de acceso— es una medida de preparación, no un detalle técnico.
Correlacionar evidencia física y lógica
El caso combina dos mundos que en las empresas suelen estar en manos distintas: lo que graba una cámara o registra un control de acceso, y lo que escriben los servidores. Ninguno se basta solo. La cámara dice quién o qué había en una sala, pero no qué pasó en la red; el log dice qué cuenta y desde qué dirección, pero no quién estaba detrás del teclado.
Correlacionar es cruzarlas, y las etiquetas físicas (de un rack, de un puesto) también son evidencia. La seguridad física es parte del incidente: un dato expuesto en un puesto de trabajo es una vulnerabilidad igual que un puerto abierto.
Las pistas falsas
Toda investigación real tiene ruido que se parece a la señal:
- Actividad legítima en la misma franja. Copias de seguridad, administradores, compañeros que trabajan a deshora.
- Coincidencia temporal no es causalidad. Que dos cosas pasen a la misma hora no las une.
- Direcciones que cambian. Un mismo dominio puede resolver a direcciones distintas a distintas horas, y una IP pública puede esconder a muchas personas detrás de un NAT o de una red de anonimato.
- Lo que se ve en pantalla no es siempre del atacante. Antes de atribuir un dato, hay que preguntarse quién lo generó.
La defensa es metodológica: hipótesis, evidencia a favor, evidencia que la contradiría y comprobación. Si el equipo se atasca, vuelve a la evidencia.
Contener sin hacer daño
La contención tiene que ser proporcionada y precisa:
- Bloquear la dirección concreta, no una red entera que puede incluir servicios legítimos. En un servidor con UFW, una regla de salida (
ufw deny out to …) corta la exfiltración sin tocar el resto. - Cortar la sesión del intruso, no todas las del usuario.
whoywdicen quién hay y desde dónde;psda el proceso de cada terminal.pkill -u usuarioecha a todos, incluido quien trabaja. - Bloquear la cuenta (
passwd -lousermod -L) y, después, rotar la credencial. Bloquear sin rotar solo aplaza el problema.
El informe
Lo lee dirección, no el equipo técnico. Una estructura que funciona:
| Apartado | Contenido |
|---|---|
| Resumen ejecutivo | qué pasó, impacto y estado actual, en un párrafo |
| Línea temporal | eventos en UTC (o en hora local declarada), con su fuente |
| Vector de entrada | cómo entró, con la evidencia que lo prueba |
| Alcance | qué sistemas y qué datos, y qué no se vio afectado |
| Indicadores de compromiso | direcciones, dominios, ficheros, claves |
| Acciones realizadas | contención, erradicación, recuperación, con hora |
| Lecciones y recomendaciones | qué falló en la preparación y qué cambia |
Si hay datos personales afectados —y unas nóminas lo son—, el RGPD obliga en su artículo 33 a notificar la brecha a la autoridad de control en un plazo de 72 horas desde que se tiene constancia, salvo que sea improbable que suponga un riesgo para las personas. Para una empresa privada esa autoridad es la AEPD. Eso es materia del RA5, pero el informe del caso es lo primero que se necesitaría para hacerlo.
Cómo funciona el laboratorio
Cada capítulo empieza con una grabación de unos 55 segundos que no se
puede adelantar la primera vez: lo que hace falta está en lo que se ve y en
lo que se dice, pero el vídeo nunca da la respuesta. Después viene el
terminal forense, con órdenes reales (grep, awk, cut, sort,
uniq, w, ps, ufw…) sobre ficheros de registro de verdad, y un
panel de conclusiones.
- Acceso nocturno. Lectura de
auth.log, correlación de la grabación con el registro y reconciliación de relojes. Entrena la fase de detección y análisis, y a separar el ruido de la señal. - Rastro de salida. Registros de DNS y del cortafuegos perimetral, correlación por cliente, dominio y hora, y una primera contención con el cortafuegos local. Entrena la exfiltración y la contención precisa.
- Algo se quedó dentro. Ahora se puede modificar el servidor. Buscar la persistencia, entender qué hace y quitarla sin romper lo legítimo. Entrena la erradicación.
- Contención y cierre. Sesiones activas, bloqueo de cuentas y la reconstrucción ordenada de la línea temporal. Entrena la contención sin daños colaterales y el cierre del incidente.
En los capítulos 2 a 4 la orden comprobar verifica los cambios en el
servidor y da un código; restaurar deja el capítulo como al principio.
Las pistas existen, tres por capítulo, y cuestan minutos.
Cada capítulo vale 25 puntos, que bajan con las respuestas incorrectas, los
comprobar fallidos y las pistas. Al final sale un informe imprimible.
Errores habituales
- Fiarse de la primera hora que se ve, sin saber qué reloj hay detrás.
- Confundir intento con acceso, en los dos sentidos.
- Atribuir por cercanía: una IP o una sesión próxima al incidente no es del atacante por estar cerca.
- Contener a lo bruto: redes enteras, todas las sesiones, apagar.
- Erradicar sin conservar copia ni resumen de lo borrado.
- Cerrar sin rotar la credencial.
- Escribir el informe para técnicos, cuando quien decide es dirección.
Notas para el profesorado
- Equipos de tres o cuatro, un navegador por equipo. Funciona mejor si uno lleva el terminal, otro las notas y otro la línea temporal, y rotan en cada capítulo.
- Auriculares por equipo: cada equipo revisa los vídeos a su ritmo; el proyector queda para la puesta en común.
- Ritmo: unas cuatro horas. Si se parte en dos sesiones, el corte natural es después del capítulo 2. El progreso se guarda en el navegador, así que el equipo tiene que volver al mismo equipo y al mismo navegador.
- Seguimiento: cada capítulo resuelto da un código de avance para el docente, y el informe final uno de verificación con equipo, puntuación y tiempo.
- Las respuestas se guardan como resumen con sal en el propio cliente. Eso impide leerlas en el código fuente, pero no resiste fuerza bruta cuando el espacio de respuestas es pequeño. Sirve para clase, no para calificar; en un módulo de ciberseguridad se puede proponer, después, como ejercicio.
- Sin red: el laboratorio es una carpeta (página, guiones, datos y vídeos) y no envía nada a ningún sitio. Se puede copiar entera a un pendrive; si al abrirla como fichero el navegador no carga los subtítulos, basta con servirla en local (
python3 -m http.server).
Preguntas para la puesta en común:
- ¿Qué fuente os hizo dudar de una hora, y cómo lo resolvisteis?
- ¿Qué pista falsa os costó más descartar, y qué evidencia la descartó?
- ¿Qué medida de preparación habría evitado el incidente? ¿Y cuál lo habría detectado antes?
- Si mañana tuvierais que notificarlo, ¿a quién, en qué plazo y con qué datos?