Cazar lo que no encaja

Hasta ahora siempre hubo un aviso: una alerta, un dato raro señalado, alguien diciendo «mira esto». En el trabajo real eso es el caso fácil, y es el minoritario.

El caso normal es este: nadie ha avisado, todo parece bien, y aun así hay que buscar. Se llama búsqueda proactiva, y la razón de que exista es incómoda: las alertas solo detectan lo que alguien programó de antemano. Un ataque que no se parece a ninguna regla escrita no genera ninguna alerta, y el panel se queda en verde.

Buscar sin aviso funciona al revés que buscar con aviso. No se empieza por «¿qué pasó?», se empieza por una hipótesis:

«Si alguien estuviera dentro de esta máquina, ¿dónde se vería?»

Y esa pregunta se puede contestar, porque estar dentro obliga a hacer cosas: ejecutar algo, guardar algo, conectar a algún sitio. Cada una deja un sitio donde mirar.

Abre el laboratorio. Es el segundo servidor de la clínica, el de respaldos, y viene con un encargo en la carpeta de inicio:

cat encargo.txt

Léelo entero antes de seguir. Y fíjate en cómo empieza: no ha saltado ninguna alerta. El panel está en verde. Esa es exactamente la situación de la que va la sala.

Quien está dentro de una máquina tiene que hacer cuatro cosas, y cada una tiene su sitio. Esta es la lista que se recorre, y sirve en cualquier sistema:

Quién entró. Los registros de autenticación. Se busca: horas imposibles, usuarios que no deberían entrar por ahí, y sobre todo muchos fallos seguidos con un acierto justo después — que es la firma de un ataque a base de probar contraseñas que funcionó.

Qué se está ejecutando. La lista de procesos, con ps. Se busca: nombres que imitan a los del sistema, rutas donde no debería vivir un programa, y procesos cuyo dueño no cuadra con lo que hacen.

Qué se guardó. Los archivos y sus permisos, con ls -l. Se busca: quién es el dueño, quién puede escribir, y desde cuándo está ahí.

Con quién habla. Las conexiones salientes. Se busca: regularidad. Un humano navega a ratos, en cantidades desiguales; un programa que llama a casa lo hace cada tantos minutos exactos, con el mismo tamaño siempre.

Y aquí está el criterio que ordena las cuatro, y que es lo que hay que llevarse de esta sala:

No se busca lo malo, se busca lo que no encaja.

Nadie puede tener en la cabeza la lista de todo el software dañino que existe, y esa lista además no serviría: lo nuevo no está en ella. Pero cualquiera puede notar que algo está en el sitio equivocado, o es de quien no debería ser.

Con la lista en la mano, recorre la máquina. Aviso antes de empezar: aquí no hay nada que grite. No hay 4.600 errores ni un programa en /tmp. Si esperas eso, vas a cerrar la sala diciendo que está limpia.

Quién entró:

cat /var/log/auth.log

Lee las horas de la madrugada. Cuenta los fallos y mira qué línea viene justo después del último. Esa línea es el hallazgo.

Qué se está ejecutando:

ps

Aquí es donde hay que tener cuidado. Todos los nombres son de servicios normales y todas las rutas son correctas. Así que no mires las rutas: mira la columna del usuario, y pregúntate para cada línea si ese programa debería estar corriendo como ese usuario.

Pista de método: nginx como www-data está bien, porque el servidor web es suyo. Un demonio del sistema como www-data, no.

Qué se guardó:

ls -l /usr/sbin

Cuando tengas el proceso raro, mira su archivo. El dueño y los permisos terminan de contar la historia — y hay una nota de turno en esa misma carpeta.

Con quién habla:

cat /var/log/salidas.log

Mira las horas y los tamaños. Cuatro conexiones, siempre el mismo destino, siempre el mismo tamaño, exactamente cada cinco minutos. Eso no lo hace una persona.

Y conviene que sepas que el trabajo real se siente así: la mayoría de las veces no encuentras nada, y eso también es un resultado. Un turno entero mirando sin hallazgos no es un turno perdido; es una hipótesis descartada, y se apunta como tal.

Junta lo que tienes: alguien probó contraseñas contra la cuenta respaldo a las tres de la mañana, acertó a la quinta, dejó un programa corriendo con el nombre de un servicio del sistema, y ese programa manda 512 bytes al mismo sitio cada cinco minutos.

Eso ya no son cuatro cosas raras. Es una sola historia, y por eso se miran los cuatro sitios y no uno.

Pero no has terminado: has empezado. El error clásico aquí es correr a matar el proceso y dar el asunto por cerrado.

Porque si lo matas ahora, pierdes tres respuestas que solo se pueden conseguir con él vivo:

¿Cómo entró? Sin eso, lo cierras hoy y vuelve mañana por la misma puerta.

¿Desde cuándo? Decide todo lo demás: a cuánta gente hay que avisar, qué datos salieron, qué copias de seguridad están limpias.

¿Está en más máquinas? Casi siempre la respuesta es sí, y limpiar una sola deja el problema entero.

Así que un hallazgo se convierte en tres preguntas, y cada una en más sitios donde mirar. Eso es investigar un incidente, y es la razón de que estas cosas duren semanas y no tardes.

Con una excepción que manda sobre todo lo anterior: si el daño está pasando ahora mismo —datos saliendo, archivos cifrándose— se corta primero y se investiga después. Los datos que salen no vuelven.

Y esa excepción es justo la de esta máquina. Vuelve a mirar salidas.log: la última conexión es de hace unos minutos y la siguiente sale en cinco. Esto no es un rastro de algo que pasó; está pasando.

Así que aquí no se investiga con calma. Se corta la salida hacia ese destino —que es lo que hiciste en el panel del módulo 1— y después se contestan las tres preguntas, con el proceso ya sin conexión pero todavía en la máquina para poder estudiarlo.

Fíjate en el matiz, porque es donde se equivoca casi todo el mundo: cortar la salida no es matar el proceso. Lo primero detiene el daño y conserva las pruebas. Lo segundo detiene el daño y las borra.

Y una última cosa, que es la que hace que todo esto sirva de algo: lo que encontraste hay que escribirlo. Ahora mismo el hallazgo vive solo en tu cabeza y en el desplazamiento de una terminal. Eso es lo que arregla la sala siguiente.