SOC en casa: Laboratorio de detección de amenazas con Wazuh + Suricata

Un laboratorio de Centro de Operaciones de Seguridad autogestionado, diseñado para detectar técnicas de ataque reales contra un objetivo deliberadamente vulnerable, usando Wazuh como SIEM y Suricata como sensor IDS basado en red. Construido para demostrar habilidades de ingeniería de detección — no solo despliegue de herramientas.

Descripción general

El trabajo moderno en un SOC no consiste solo en "instalar un SIEM y mirar el panel". Se trata de entender por qué existe una brecha de detección y saber cómo cerrarla. Este laboratorio simula un entorno pequeño y realista: una máquina atacante, un objetivo heredado/vulnerable sin soporte de registro nativo y una pila SIEM que debe trabajar alrededor de esa limitación utilizando visibilidad a nivel de red en lugar de agentes en el host.

Decisión arquitectónica clave: el objetivo (Metasploitable 2) ejecuta un sistema operativo demasiado antiguo para admitir un agente Wazuh moderno o incluso un reenviador de syslog con acceso a Internet. En lugar de tratar esto como un bloqueador, el proyecto gira hacia la detección completamente basada en red a través de Suricata — un patrón realista para activos heredados, IoT u OT que no pueden ser instrumentados directamente.

Arquitectura

┌─────────────┐         attacks          ┌──────────────────────┐
│   Kali VM   │ ────────────────────────▶│   Metasploitable 2   │
│ (attacker + │                           │  (unmonitored victim, │
│  Suricata   │                           │   no agent, no       │
│  sensor +   │                           │   internet access)   │
│  Wazuh agent│                           └──────────────────────┘
└──────┬──────┘
       │ eve.json (Suricata alerts/events)
       │ forwarded via Wazuh agent
       ▼
┌─────────────────────┐
│   Wazuh Manager      │
│   (Amazon Linux 2023)│
│   Indexer + Dashboard│
└─────────────────────┘

Las tres máquinas virtuales se ejecutan en VirtualBox, con red NAT en 192.168.0.0/24.

Por qué Suricata se ejecuta en la máquina atacante

Suricata necesita visibilidad del tráfico entre el atacante y el objetivo. Existen dos opciones: una VM de sensor dedicada con una interfaz en modo promiscuo/duplicada, o ejecutar el sensor en uno de los dos hosts que ya están en la ruta del tráfico. Dado que el gestor Wazuh (Amazon Linux 2023) no tiene soporte de EPEL y hacía poco práctico instalar Suricata, y el objetivo no puede ejecutar ningún agente, Suricata se ejecuta directamente en la máquina Kali. Esto significa que ve el 100% del tráfico de ataque en su propia interfaz sin necesidad de modo promiscuo ni puerto SPAN, y envía sus eventos al gestor a través del agente Wazuh ya registrado en Kali.

Detecciones

1. Reconocimiento — Detección de escaneo Nmap

Ataque:

nmap -sV -A 192.168.0.138

Detección: el conjunto de reglas Emerging Threats de Suricata marcó múltiples firmas de escaneo y anomalías de protocolo en tiempo real a medida que el escaneo tocaba cada puerto abierto, incluido el tráfico hacia el servicio UnrealIRCd expuesto de Metasploitable (ET CHAT IRC USER command).

Resultado: se generaron 132+ eventos IDS registrados y correctamente clasificados bajo los grupos de reglas ids, suricata en la vista de caza de amenazas de Wazuh a los pocos segundos de finalizar el escaneo.

2. Explotación — Puerta trasera en vsftpd 2.3.4 (CVE-2011-2523)

Ataque:

msf6 > use exploit/unix/ftp/vsftpd_234_backdoor
msf6 > set RHOSTS 192.168.0.138
msf6 > set LHOST 192.168.0.200
msf6 > run

El vsftpd 2.3.4 de Metasploitable contiene una puerta trasera que se activa con una cadena de inicio de sesión FTP malformada, la cual abre una shell root en el puerto TCP 6200. El exploit se ejecutó limpiamente y devolvió una sesión de Meterpreter como root.

Detección: la firma GPL ATTACK_RESPONSE id check returned root de Suricata (SID 2100498) se disparó 11 segundos después de que se generara la shell, al coincidir con la cadena en texto plano uid=0(root) en la salida de comandos de la shell mientras cruzaba el cable en el puerto 6200.

"signature": "GPL ATTACK_RESPONSE id check returned root",
"signature_id": 2100498,
"src_ip": "192.168.0.138",
"src_port": 6200,
"dest_ip": "192.168.0.200",
"direction": "to_client"

Por qué es importante: esta es una confirmación a nivel de red del compromiso exitoso de root en un activo con cero registro basado en host, exactamente el escenario para el que fue diseñada la arquitectura.

3. Ataque de credenciales — Fuerza bruta FTP (MITRE ATT&CK T1110)

Ataque:

hydra -l msfadmin -P /tmp/quicklist.txt -t 4 ftp://192.168.0.138

Hydra probó múltiples inicios de sesión FTP en rápida sucesión, identificando correctamente el par de credenciales válido msfadmin:msfadmin después de varios intentos fallidos.

Estado de la detección: el analizador de protocolo FTP de Suricata capturó cada comando individual USER/PASS y el correspondiente código de respuesta del servidor en eve.json (event_type: ftp), confirmado presente en el archivo de eventos sin procesar del gestor:

{"event_type":"ftp","src_ip":"192.168.0.200","dest_ip":"192.168.0.138",
 "dest_port":21,"ftp":{"command":"PASS","command_data":"root",
 "completion_code":["530"],"reply":["Login incorrect."]}}

El conjunto de reglas predeterminado de Suricata no tiene una firma dedicada para la fuerza bruta FTP, ya que es un patrón de protocolo en lugar de una cadena conocida maliciosa. Se diseñó una regla de correlación personalizada de Wazuh para cerrar esta brecha:

<group name="suricata,ftp,brute_force,">
  <rule id="100100" level="5">
    <if_sid>86600</if_sid>
    <field name="event_type">^ftp$</field>
    <field name="data.ftp.command">^PASS$</field>
    <description>Suricata: FTP password attempt detected on $(data.dest_ip)</description>
  </rule>

  <rule id="100101" level="10" frequency="4" timeframe="60">
    <if_matched_sid>100100</if_matched_sid>
    <description>Suricata: Possible FTP brute force attack detected - multiple password attempts within 60 seconds</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

Estado: en curso — se confirma que los datos de eventos subyacentes llegan al gestor, y la sintaxis de la regla se valida mediante wazuh-logtest, pero la regla de correlación (100101) aún no se activa de manera fiable de extremo a extremo. El siguiente paso de depuración es confirmar la ruta del campo del decodificador asignada a los campos FTP anidados de Suricata en el momento del análisis mediante wazuh-logtest con una muestra en vivo. Se registra como trabajo futuro a continuación.

Lecciones aprendidas

• Los objetivos heredados cambian tu arquitectura, no solo tus comandos. El conjunto de herramientas desactualizado de Metasploitable 2 descartó un agente Wazuh moderno e incluso el reenvío básico de syslog (sin rsyslog, sin acceso a Internet). En lugar de forzar un enfoque basado en host, el proyecto giró hacia la detección basada en red — posiblemente un patrón más realista para activos heredados/IoT del mundo real.
• Los ecosistemas de paquetes no son intercambiables. La base Amazon Linux 2023 del gestor Wazuh no admite EPEL clásico, lo que bloqueó una instalación directa de Suricata allí. Trasladar el sensor a la máquina Kali basada en Debian, que ya estaba en la ruta del tráfico, evitó el problema por completo.
• Los conjuntos de reglas IDS predeterminados están basados en firmas, no en comportamiento. Suricata detectó el exploit de vsftpd al instante porque existía una firma conocida, pero no tenía nada para la fuerza bruta FTP porque eso es un patrón, no una cadena estática. Esta es la justificación real para escribir reglas de correlación personalizadas en un SIEM en lugar de depender únicamente del contenido IDS listo para usar.
• archives.log/archives.json no están habilitados de forma predeterminada (logall/logall_json están en no de serie) y son esenciales para depurar lo que un SIEM realmente recibió versus aquello sobre lo que eligió alertar.

Trabajo futuro

• Terminar la depuración de la regla de correlación de fuerza bruta FTP (100100/100101) de extremo a extremo
• Añadir la explotación de la puerta trasera de UnrealIRCd (CVE-2010-2075) como cuarta detección, ya que Suricata ya está marcando tráfico IRC en el objetivo
• Añadir la RCE de Samba usermap_script (CVE-2007-2447) como quinta técnica
• Conectar alertas de alta severidad a TheHive o Shuffle para la creación automatizada de casos
• Añadir respuesta activa para bloquear automáticamente la IP del atacante ante detecciones repetidas de fuerza bruta

Herramientas utilizadas

• Wazuh 4.14.6 — SIEM (gestor, indexador, panel)
• Suricata 8.0.5 — IDS de red
• Metasploit Framework / Hydra / Nmap — simulación de ataques
• VirtualBox — virtualización del laboratorio

Mapeo MITRE ATT&CK