Writeup: cómo leer tu primer log y cazar una fuerza bruta

Cómo leer un auth.log y detectar una fuerza bruta por SSH, el primer reflejo de un analista de un SOC. El método completo, sin darte las respuestas.

Cómo leer un auth.log y cazar una fuerza bruta por SSH, el primer reflejo de cualquier analista de un SOC. Aquí va el método completo. Las respuestas las capturas tú, en el lab gratis del final.

Qué es un auth.log y por qué te importa

Cuando alguien intenta entrar a un servidor Linux por SSH, el sistema lo apunta en un archivo de registro: el auth.log. Cada intento, acertado o fallido, deja una línea. Aprender a leer ese archivo es, literalmente, lo primero que hace un analista en su primer día. No hace falta ninguna herramienta cara: con el Bloc de notas y un poco de grep te sobra.

Anatomía de una línea

Una línea de acceso por SSH se lee así:

Jul  3 08:15:02 web-prod-1 sshd[1140]: Accepted password for ana from 10.0.2.14 port 55020 ssh2
     fecha/hora        host            resultado        usuario     IP de origen

Dos palabras te dicen casi todo:

• Accepted: el login funcionó.
• Failed: el login falló.

Con eso ya puedes separar el ruido de lo que importa.

El patrón de una fuerza bruta

Un atacante que adivina contraseñas no es sutil: prueba una y otra vez. En el log eso se ve como muchas líneas Failed password seguidas, casi siempre contra la misma cuenta y desde la misma dirección IP. Es un rastro clarísimo cuando sabes qué buscar.

Para aislar solo los intentos fallidos:

grep "Failed password" auth.log

Fíjate en dos cosas mientras lees el resultado:

• La IP que se repite al final de las líneas. Las conexiones internas normales vienen de un rango conocido (por ejemplo 10.0.2.x). La que insiste desde fuera, machacando, es la sospechosa.
• La cuenta que va después de for. El atacante no prueba al azar: elige una cuenta con privilegios y se centra en ella.

El momento en que entró

Después de decenas de fallos, si la contraseña cae, aparece una línea distinta: un Accepted password para esa misma cuenta y desde esa misma IP. Ese es el instante de la brecha.

grep "Accepted password" auth.log

La clave del análisis es correlacionar: no te quedes con cualquier Accepted, busca el que coincide en cuenta y en IP con la fuerza bruta que ya identificaste. Las demás conexiones aceptadas son tráfico interno legítimo y te despistan si no las descartas.

Las tres preguntas del incidente

Cuando termines, tendrás que responder lo mismo que se responde en un parte real:

1. Quién: la IP del atacante.
2. A quién: la cuenta que intentaba comprometer.
3. Cuándo: la hora exacta en que lo consiguió.

No te doy los valores a propósito. La gracia está en sacarlos tú: es la diferencia entre haber leído un walkthrough y saber hacerlo cuando lo pregunten en una entrevista.

Por qué esto es exactamente tu trabajo

Esa correlación que acabas de hacer a mano ("N fallos y luego un éxito desde la misma IP contra la misma cuenta") es una de las primeras reglas que se montan en un SIEM. Automatizarla es media carrera de un analista de detección. Empezaste por el sitio correcto.

Ahora hazlo tú

El log completo y las tres flags te esperan en el lab, gratis y sin instalar nada:

Primeros pasos #1: tu primer log

Es el primero de la ruta de iniciación en Blue Team. Cuando la completes entera, te llevas la credencial Blue Team Operator I para tu LinkedIn.