El Rincon de Jose

Foto de MARIOLA GROBELSKA en Unsplash

Enciendo los dos servidores principales (Wazuh y OpenCTI/TheHive/Shuffle...), manteniendo todavía apagado el agente Debian.
Nada más arrancar, voy a TheHive y... ¡sorpresa! Ya tenemos nuestro primer caso recién creado.

¿Por qué ha saltado esta alerta si el agente no estaba encendido?
Muy sencillo: el propio Manager de Wazuh se monitoriza a sí mismo. Al iniciar sus servicios internos (como wazuh-remoted en el puerto 1514 o Velociraptor), ha detectado la apertura de estos puertos y ha generado una alerta interna de cambio de estado. Como esta alerta no contiene etiquetado MITRE, Shuffle la ha canalizado por la rama estándar (Http 3), etiquetándola impecablemente en TheHive como Wazuh / Normal.
¡El pipeline de ingesta automática funciona solo con encender las máquinas!"
¡Ya tenemos la primera prueba de que la rama genérica (Http 3) está funcionando sola en producción!
Ahora, en cuanto arranquemos la máquina agente (Debian) y disparemos uno de los comandos del Cheat Sheet, veremos entrar por la puerta grande la rama enriquecida con OpenCTI (Http 1 ➔ Http 2).

Dudas a Gemini Web

Antes de seguir le paso mis dudas a Gemini Web.

Como se puede ver en la anterior captura, la fecha y la hora numéricamente hablando son correctas. Pero siempre me da como día de la semana el sábado.

¿Por qué TheHive pone "Sábado 31/07/2026" si la terminal de Linux dice "vie 31 jul 2026"?

1.- La fecha numérica y la hora son milimétricamente exactas (31/07/2026 06:43): Esto demuestra que tu servidor Linux, la base de datos de TheHive y el contenedor de Shuffle están en perfecta sincronía horaria (NTP/UTC/CEST). La marca de tiempo (timestamp) con la que se guardan los eventos en la base de datos es totalmente correcta.
2.- El "Sábado": Es simplemente un problema de traducción de la interfaz web (Locale/I18n) de TheHive. La interfaz tiene un bug en su paquete de idioma español donde el código de formateo mapea mal las abreviaturas de los días de la semana en la columna reducida (confunde el índice del día o traduce mal "Friday" por "Sábado" al renderizar el texto dinámico).

¿Afecta en algo?
En la base de datos / Forense: NO afecta en nada. La fecha guardada internamente es 31/07/2026 06:43 (Viernes). Si exportas los datos o haces búsquedas por fecha (startDate), todo encajará al segundo.

Fin de las dudas

Ahora voy a arrancar el servidor Debian 13 con el agente Wazuh.

Me voy a loguear correctamente y una vez que este arrancado voy a entrar con Putty a Debian con un usuario que no es el mio y una contraseña incorrecta.

Debería darme una alerta y abrir un caso en TheHive del tipo “fallo en el log del sistema”

Pero antes del intento de intrusión vemos esto;

Al iniciar sesión en el sistema, TheHive registra inmediatamente el evento de conexión del agente.
Caso #1927: Wazuh agent started. Clasificado correctamente por la rama genérica (Http 3) con etiqueta Normal.

La prueba real: Inicialización del Agente e Intento de Intrusión SSH

Para simular un intento de intrusión real, abrimos una sesión de PuTTY desde una máquina remota (192.168.1.135) e intentamos acceder por SSH introduciendo credenciales incorrectas.
Al instante, el motor de reglas de Wazuh intercepta el fallo en auth.log y Shuffle canaliza el evento hacia TheHive (image_75049a.png), creando el caso con las subtécnicas exactas identificadas por la matriz MITRE ATT&CK: ["T1110.001", "T1021.004"].

Vemos como me da la Técnica MITRE: [“T1110.001”, “T1021.004”]

T1110.001 - Password Guessing (Adivinación de Contraseñas):

Es una sub-técnica de fuerza bruta. Los atacantes prueban sistemáticamente combinaciones comunes o de diccionario para adivinar las credenciales y obtener acceso a un sistema, a menudo sin conocimiento previo de las políticas de la organización.

T1021.004 - Remote Services: SSH (Servicios Remotos: SSH):

Es una técnica de movimiento lateral. Los atacantes utilizan cuentas válidas y el protocolo Secure Shell (SSH) para iniciar sesión de forma remota en otros equipos (como servidores Linux, macOS o ESXi) y ejecutar comandos con los privilegios del usuario

Al enviar Wazuh un vector con múltiples técnicas combinadas ["T1110.001", "T1021.004"], la consulta directa a OpenCTI devuelve [], pero el SOAR garantiza que el caso se aperture en TheHive con la traza de log completa y su etiquetado táctico).

La Prueba Final: Simulación de Escalada de Privilegios (T1078 / T1548)
Para esta prueba final, vamos a ejecutar en la terminal del agente Debian 13 un comando que fuerce la lectura de un fichero sensible del sistema usando sudo.
Abrimos la consola de Debian y lanzamos:

sudo cat /etc/shadow

¿Qué sucede internamente en el pipeline?
Detección en Wazuh: El módulo auditd / PAM de Wazuh detecta el acceso de superusuario al archivo de contraseñas y asigna la técnica T1078 (Valid Accounts) o T1548 (Abuse Elevation Control Mechanisms).
Procesamiento en Shuffle: El nodo Shuffle Tools 1 aísla el código de la técnica y, al ser una cadena limpia, dispara la Query GraphQL hacia OpenCTI (Http 1).
Respuesta de Ciberinteligencia: OpenCTI localiza el patrón de ataque exacto en su base de datos de amenazas y devuelve su nombre oficial y la descripción técnica completa.
Apertura en TheHive: El nodo Http 2 crea la ficha del caso, inyectando de forma automatizada tanto el evento de Wazuh como el contexto táctico de OpenCTI.
¡El resultado es un caso en TheHive con contexto forense inmediato, permitiendo al analista comprender el alcance de la amenaza sin tener que salir de la plataforma!

El resultado en TheHive habla por sí solo:
1.- Detección del Log: Wazuh registra pam_unix(sudo:session): sesión abierta para el usuario root(uid=0) por jose(uid=1000).
2.- Parsing del código MITRE: Shuffle aísla perfectamente la técnica limpia T1078.
3.- Enriquecimiento contextual de OpenCTI: La consulta GraphQL devuelve el nombre oficial de la amenaza (Valid Accounts) y la literatura explicativa completa sobre el abuso de credenciales y escalada de privilegios.
4.- Creación del Caso: TheHive genera el ticket etiquetado como ["Wazuh", "INGLETE", "[\"T1078\"]"] con la traza de log original y la inteligencia de amenazas integrada.

Tengo mas dudas que le traslado a Gemini Web

Jose

Si ejecuto, por ejemplo, cat /etc/group, no me pide la contraseña, no me salta la alerta y sin embargo me sigue dando la información en consola...si ejecuto sudo cat /etc/group me pide la contraseña, me da la información igualmente y si me salta la alerta y crea el caso...¿Es una contradicción?

Respuesta de Gemini Web

La clave no está en la información que lees, sino en CÓMO y CON QUÉ PRIVILEGIOS la estás leyendo

El misterio de sudo vs cat. En ciberseguridad, esa diferencia entre "lo que lee el usuario" y "cómo lo vigila el sistema" es pura oro molido para entender cómo operan los SIEM/SOAR.

¿Por qué cat normal NO salta y sudo cat SÍ salta?
1. Con cat /etc/group (Lectura normal)
Permisos: En Linux, /etc/group es un archivo de lectura pública (-rw-r--r--).
Acción: Como el usuario jose ya tiene permiso para leerlo, lo lee directamente.
Seguridad: El sistema considera que es una acción rutinaria y totalmente legítima. No usa el módulo PAM, no eleva privilegios y no genera un registro de auditoría en los logs del sistema.
Resultado en Wazuh: Como no hay traza en /var/log/auth.log, Wazuh no se entera y el SIEM/SOAR no dispara ningún caso.

2. Con sudo cat /etc/group (Uso de privilegio administrativo)
Acción: No estás leyendo el archivo como jose, estás invocando la herramienta sudo para ejecutar una orden como root (superusuario).
Seguridad: Invocar sudo siempre activa el mecanismo de elevación de control y el módulo de autenticación PAM. PAM solicita la contraseña y escribe obligatoriamente un evento de auditoría en /var/log/auth.log:
"pam_unix(sudo:session): sesión abierta para el usuario root por jose".
Resultado en Wazuh: Wazuh lee esa línea en el log, detecta que un usuario ha elevado privilegios a root (técnica T1078 / T1548 de MITRE ATT&CK), manda la alerta a Shuffle, consulta a OpenCTI y te abre el caso en TheHive.
En resumen: Lo que monitorea Wazuh no es el comando cat, sino el uso de sudo
No hay contradicción:
Lo que importa no es la salida en pantalla (que es la misma en ambos casos porque el archivo es público).
Lo que dispara la alerta de seguridad es el uso de sudo.
En ciberseguridad, que un usuario use sudo (elevación de privilegios) cuando no lo necesita es una anomalía o un comportamiento sospechoso que un SOC siempre debe registrar.

Para quienes estéis montando este laboratorio en casa y queráis comprobar cómo reacciona vuestro SOAR ante distintas amenazas, os dejo esta guía rápida de comandos para ejecutar en el agente Linux y disparar diferentes reglas de seguridad:

1. T1059 – Command Execution (execve)

Todo lo que ejecute un binario genera `EXECVE`.

ls -l

whoami

uname -a

ps aux

Con sudo (escalada):

sudo ls -l /root

sudo cat /etc/shadow

sudo tail -f /var/log/auth.log

2. T1548 – Privilege Escalation (sudo)

Cada vez que usas sudo, auditd registra:

sudo -l

sudo su

sudo id

sudo cat /etc/passwd

sudo cat /etc/shadow

sudo nano /etc/sudoers

3. T1003 – Credential Access (lectura de ficheros sensibles)

Estas reglas las tienes activadas, así que cualquier lectura dispara alerta:

cat /etc/passwd

cat /etc/shadow

cat /etc/group

sudo cat /etc/shadow

sudo grep root /etc/shadow

4. T1098 – Account Manipulation (usuarios y grupos)

Cambios en usuarios:`

sudo useradd atacante

sudo userdel atacante

sudo passwd jose

sudo passwd root

Cambios en grupos:

sudo groupadd malicioso

sudo groupdel malicioso

sudo usermod -aG sudo jose

5. T1053 – Scheduled Tasks (cron)

Cambios en cron:

sudo nano /etc/crontab

sudo nano /etc/cron.d/prueba

sudo crontab -e

6. T1543 – Create or Modify System Process (systemd)

Cambios en servicios:

sudo nano /etc/systemd/system/prueba.service

sudo systemctl daemon-reload

sudo systemctl start prueba.service

7. T1574 – Hijack Execution Flow (binarios del sistema)

Cambios en binarios:

sudo touch /usr/bin/falso

sudo chmod +x /usr/bin/falso

sudo rm /usr/bin/falso

8. T1110 – Brute Force (fallos de login)

Simular fallos de login:

ssh jose@localhost

# Introduce contraseña incorrecta varias veces

O desde otra máquina:

ssh jose@IP_DEL_SERVIDOR

9. T1078 – Valid Accounts (sesiones)

Abrir y cerrar sesiones:

ssh jose@localhost

exit

10. T1027 – Obfuscated / Suspicious Execution

Ejecutar comandos raros:

bash -c "ls"

sh -c "id"

11. T1083 – File Discovery

Enumeración de ficheros:

find /etc -type f

find /home -type f

12. T1046 – Network Scanning

Si tienes reglas de red activas:

ping 8.8.8.8

netstat -tulnp

ss -tulnp

13. T1057 – Process Discovery

Procesos:

ps aux

top

htop

14. T1105 – Ingress Tool Transfer

Descargar ficheros:

wget http://example.com/fichero

curl http://example.com/fichero

15. T1140 – Deobfuscate / Decode Files

Comandos de decodificación:

base64 /etc/passwd

base64 -d fichero.txt

👉 Todos estos comandos generan eventos auditd

👉 Wazuh los recoge y correlaciona con MITRE

👉 Shuffle recibe MITRE limpio

👉 Si MITRE existe → Http1 + Http2 → OpenCTI + TheHive

👉 Si MITRE no existe → Http3 → caso simple

👉 El SOC queda probado de arriba abajo

Después de, jajajajajaja, una travesía en el desierto de casi 40 días, por fin puedo dormir como un niño al ver los resultados de la configuración de Shuffle, OpenCTI y Wazuh para que la magia aparezca en TheHive.
Cuando acabé el módulo y me quedé con la copla de tener instalado Wazuh + TheHive + Cortex + MISP, no sabía lo que me esperaba al seguir integrando y configurando el resto de las herramientas del SOC.
Pero ha merecido la pena. Cada hora, cada error y cada prueba.
Si has llegado hasta aquí igual que yo, ¡Enhorabuena!

Seguimos navegando juntos hasta el final.

Barakaldo 1 de agosto de 2026