Wazuh (SIEM + XDR Open Source, Rules as Code)

Nota da subpasta 02 - Plataformas de Detecção e Resposta, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Wazuh como plataforma open source de SIEM e XDR: arquitetura, ruleset e decoders, regras como código, active response e integração com VirusTotal e CTI.
Dialoga com as notas de Elastic Security e Splunk da mesma pasta, com a nota de telemetria interna do Capítulo 02 e com o controle PRT.1 do Capítulo 15.

1. Contexto e Posicionamento na Biblioteca

Quando o orçamento não comporta EDR comercial mais SIEM licenciado, o Wazuh é a resposta open source mais completa que o mercado oferece: coleta de telemetria de endpoint, análise de logs, detecção com ruleset versionado, resposta automatizada e dashboards, tudo sob licença aberta. Para o programa de CTI-TH, ele ocupa o papel de plataforma de detecção em que a inteligência do Capítulo 10 vira regra e o controle PRT.1 do Capítulo 15 ganha execução sem custo de licença. A comparação com Elastic Security e Splunk desta mesma pasta mostra os três níveis de investimento; o Wazuh é o de entrada, com a exigência inversa: mais trabalho de operação própria.

A nota segue o desenho do produto, arquitetura primeiro, depois o ciclo de escrita de regras e decoders, o modelo de resposta ativa e as integrações de inteligência, e fecha com casos de uso de CTI-TH em orçamento limitado e um exemplo completo de regra customizada com resposta. A tese que atravessa tudo é que o valor do Wazuh para o time é proporcional à disciplina de tratar o ruleset como código, e não como configuração solta no servidor.

2. Arquitetura: Agent, Server, Indexer e Dashboard

A arquitetura tem quatro componentes. O agent roda nos endpoints Windows, Linux e macOS e coleta eventos de log, integridade de arquivos, inventário, vulnerabilidades e telemetria de processos e rede, enviando ao server em canal cifrado. O server, historicamente chamado de manager, é o cérebro: recebe eventos, aplica decoders e regras, gera alertas, executa active responses e expõe API de administração. O indexer, baseado em OpenSearch, indexa alertas e eventos arquivados, e o dashboard, baseado em OpenSearch Dashboards, entrega busca, visualização e os módulos de gestão do produto.

O desenho de escala típico para o capítulo é um cluster de server por região com balanceamento dos agentes, um par de indexer com réplicas e um dashboard. A tabela resume o papel de cada componente e o ponto de atenção operacional de cada um.

A implantação de referência para começar é modesta: um server, um indexer e o dashboard, com agentes distribuídos por grupos que espelham a criticidade dos ativos. O agrupamento por grupo de agentes importa mais do que parece, porque define ruleset aplicável, active response permitida e política de coleta por classe de host. A evolução para cluster acontece por demanda real de eventos por segundo, e o dimensionamento deve acompanhar o crescimento do archive, e não apenas do volume de alertas.

A coleta em Windows usa Sysmon quando instalado, e a nota de telemetria interna do Capítulo 02 define o baseline de eventos que vale habilitar; a regra prática do capítulo é que o Wazuh só detecta o que o agente e o sistema operacional entregam, e a riqueza de detecção acompanha a riqueza da coleta.

3. Ruleset, Decoders e CDB Lists

O pipeline de análise do server tem três camadas. Os decoders normalizam logs brutos em campos estruturados, combinando decoders pré-definidos do ruleset oficial com decoders customizados em XML quando o log foge do padrão. As regras classificam os eventos decodificados em níveis de 0 a 15, agrupadas por categorias e enriquecidas com mapeamento MITRE ATT&CK por regra. As CDB lists são listas de consulta em memória, por exemplo usuários privilegiados ou hosts servidores, que regras consultam no momento da avaliação para dar contexto sem banco externo.

O ruleset oficial é atualizado continuamente pelo fornecedor e cobre milhares de regras, mas a regra de ouro operacional é a mesma do Elastic: regras do fornecedor são conteúdo atualizável, regras locais são propriedade do time, e a separação vive em diretórios distintos. O arquivo ossec.conf declara a ordem de inclusão, e é nele que o controle de versão se ancora, como a seção seguinte detalha.

As CDB lists merecem atenção especial do programa de CTI-TH, porque são o mecanismo mais barato de injetar inteligência na avaliação em tempo real. O formato é chave e valor em arquivo plano, versionado no mesmo repositório das regras, e a regra consulta a lista por campo decodificado.

# /var/ossec/etc/lists/usuarios-privilegiados
administrador:enabled
svc-backup:enabled
adm-ti-01:enabled

4. Rules as Code no Wazuh

Tratar regras como código no Wazuh significa três práticas. Primeiro, manter /var/ossec/etc/rules/local_rules.xml e /var/ossec/etc/decoders/local_decoders.xml sob Git, com toda mudança de regra via pull request revisado, nunca edição direta no servidor. Segundo, testar toda regra nova com o wazuh-logtest, que recebe uma linha de log e mostra decoder aplicado, regra casada e alerta resultante, antes de qualquer deploy. Terceiro, distribuir com pipeline, usando a API do Wazuh ou sincronização de arquivos validada, para que o estado do cluster seja reprodutível.

O fluxo de trabalho completo segue o DDLC do Capítulo 18: hipótese de detecção nasce da inteligência, a regra é escrita em ambiente de teste, validada com log sintético no logtest e com eventos reais de laboratório, promovida com revisão e monitorada por métrica de sinal. O exemplo da seção 6 mostra a regra no formato real e o teste correspondente.

O mapeamento do DDLC nas práticas do Wazuh fica explícito na tabela a seguir, e serve de checklist para a auditoria do processo de regras.

5. Active Response e Integrações de Inteligência

A active response executa scripts no manager ou no endpoint quando um alerta cruza o limiar configurado. Os scripts nativos cobrem bloqueio de IP por firewall, interrupção de conexão e ações de contenção, e scripts customizados em shell ou PowerShell estendem o alcance, sempre com janela de timeout e lista de permissões para evitar contenção de ativos críticos por engano. A regra de engenharia é conservadora: resposta ativa automática só para alertas de alta confiança e de baixo risco de dano colateral, e o restante vai para aprovação humana pelo SOAR do Capítulo 11.

A integração de inteligência embarcada mais usada é o módulo de VirusTotal, que consulta hashes de arquivos detectados por FIM ou por telemetria de integridade e anexa o veredito ao alerta, com quota de API a monitorar. O consumo de CTI externo segue o padrão de CDB list atualizada por script ou de busca de IOC por API, transformando feed da TIP da pasta 01 deste capítulo em lista consultável pelo server. A configuração do integrador ilustra o encadeamento.

<integration>
  <name>virustotal</name>
  <api_key>CHAVE_DA_CONTA</api_key>
  <group>sysmon_event1</group>
  <alert_format>json</alert_format>
</integration>

O desenho da lista de permissões da resposta ativa é o controle que separa automação útil de automação destrutiva: servidores de banco, controladores de domínio e hosts de missão crítica ficam fora de contenção automática, e o alcance por grupo de agentes garante o recorte. Cada script customizado entra em produção com teste em laboratório, log de execução e revisão anual, na mesma régua de um playbook de SOAR. Sem essa governança, a active response vira a principal fonte de incidentes causados pela própria defesa.

6. Casos de Uso de CTI-TH e Exemplo Completo

Para o programa de CTI-TH com orçamento limitado, quatro casos concentram o valor. Detecção de acesso inicial com telemetria de processo e integração de intel, no padrão do hunting por execução do Capítulo 08. Monitoramento de integridade de arquivos em servidores críticos, cobrindo persistência. Análise de vulnerabilidade contínua pelo inventário do agente, priorizada pela inteligência de exploração do Capítulo 05. E a base de telemetria para caça, com archives de log consultáveis no dashboard, que habilita as rodadas de hunting do Capítulo 07.

O exemplo a seguir implementa a cadeia emulada no capítulo: processo ofimático iniciando o schtasks para persistência. A regra customizada cruza decodificação do Sysmon com a cadeia de processos, mapeia ATT&CK e dispara resposta ativa de contenção do host em ambiente de teste.

<!-- /var/ossec/etc/rules/local_rules.xml -->
<group name="pt,emulacao,persistencia,scheduled_task,">
  <rule id="100410" level="12">
    <if_group>sysmon_event1</if_group>
    <field name="win.eventdata.parentImage" lookup="regex">WINWORD.EXE|EXCEL.EXE</field>
    <field name="win.eventdata.image">schtasks.exe</field>
    <field name="win.eventdata.commandLine" lookup="regex">/create|/Create</field>
    <description>Processo ofimatico criando tarefa agendada: possivel persistencia pos-macro (T1053.005)</description>
    <mitre><id>T1053.005</id></mitre>
  </rule>
</group>

<!-- Trecho em /var/ossec/etc/ossec.conf para resposta ativa na regra 100410 -->
<active-response>
  <command>isolate-host-test</command>
  <location>local</location>
  <rules_id>100410</rules_id>
  <timeout>600</timeout>
</active-response>

O teste com wazuh-logtest recebe a linha de log do Sysmon do evento simulado e deve devolver decoder win eventchannel, regra 100410, nível 12 e o mapeamento T1053.005, e o alerta correspondente aparece no dashboard em segundos na execução real do atomic da nota de Atomic Red Team da pasta 03 deste capítulo.

O script de contenção referenciado pela resposta ativa segue o padrão abaixo, com leitura do payload, extração do campo e chamada do script nativo de bloqueio, sempre com registro no log do sistema.

#!/bin/bash
# /var/ossec/active-response/bin/contain-host-test.sh
INPUT=$(cat)
SRCIP=$(echo "$INPUT" | grep -o '"srcip":"[^"]*' | cut -d'"' -f4)
if [ -n "$SRCIP" ]; then
  /var/ossec/active-response/bin/firewall-drop add "$SRCIP" 600
  logger "contain-host-test: bloqueio de $SRCIP disparado por regra de persistencia"
fi

Para o caso de credencial vazada descrito na pasta 01 deste capítulo, a caça retroativa no dashboard do Wazuh usa os alertas de autenticação do agente, com filtro pelo usuário afetado e janela entre a data do dump e a data do alerta, e o resultado orienta a decisão de contenção. O encadeamento com a emulação fecha o ciclo purple: o atomic da pasta 03 executa a técnica em host de teste, a regra 100410 deve disparar, e o resultado entra na ficha de emulação com status detectado. Essa rotina, reexecutada a cada mudança de regra ou do ruleset oficial, é o purple teaming contínuo mais barato que existe, e o Capítulo 19 descreve a cadência recomendada.

7. Erros Comuns e Pontos de Atenção

• Editar regras direto no servidor em produção, gerando drift entre ambientes; o repositório é a verdade e o deploy é pipeline.
• Habilitar todo o ruleset em nível alto sem calibragem, produzindo volume de alertas que o SOC descarta; ajuste por baseline de duas semanas e meça com SNR.
• Escrever decoders frágeis ancorados em posições fixas do log, que quebram a cada atualização do fornecedor do log; ancore em delimitadores e campos estáveis.
• Usar active response de contenção em regra de confiança média, bloqueando estações de executivos por engano; contenção automática exige confiança alta e lista de exceções revisada.
• Ignorar a quota do VirusTotal, com integração silenciosa degradada após o limite diário; monitore resposta de erro do integrador.
• Tratar o Wazuh como EDR completo, esperando telemetria e resposta de nível comercial; complemente com EDR quando o orçamento permitir, seguindo o controle PRT.1 do Capítulo 15.
• Não arquivar eventos, guardando apenas alertas e perdendo a matéria prima de caça; o archive é o que sustenta as rodadas do Capítulo 07.
• Deixar o ruleset oficial atualizar sem revisar mudanças de nível e de agrupamento, alterando volumes de alerta sem controle; a rotina de changelog vale aqui como no Elastic.
• Rodar resposta ativa sem log de auditoria próprio, impossível de investigar depois; todo script de contenção registra quem, quando e sobre qual host.

8. Integração com o Restante da Biblioteca

A telemetria coletada pelo agente é a fonte do Capítulo 02, e os archives indexados são o playground do hunting do Capítulo 07, com as consultas por TTP do Capítulo 08 traduzidas para regras locais ao longo do programa. A integração com a TIP da pasta 01 deste capítulo segue o padrão de watchlist e API descrito no Capítulo 09, e a resposta ativa conecta-se ao AUT.5 do Capítulo 15 quando o SOAR assume a aprovação humana. O comparativo com Elastic Security e Splunk orienta a decisão por porte, e o DDLC do Capítulo 18 governa o ciclo de escrita das regras.

O fechamento desta nota é o posicionamento honesto: o Wazuh entrega detecção, resposta e base de caça a custo de licença zero, cobrando em troca disciplina de operação, engenharia de regras e gestão de infraestrutura. Para equipes pequenas e orçamentos apertados, é a diferença entre ter ou não ter plataforma; para equipes maiores, é a camada de telemetria e resposta de primeira linha que complementa SIEM e EDR comerciais, e em ambos os casos o sucesso se mede pela mesma régua: quantas hipóteses de inteligência viraram regra testada, versionada e monitorada.

Para o comparativo com Elastic Security e Splunk, a régua é custo total ao longo da maturidade: o Wazuh vence em custo de licença e em telemetria de endpoint integrada, perde em escala de busca e em ecossistema de conteúdo, e a decisão deve considerar a curva de três anos, incluindo horas de operação. Times que documentam esse comparativo com números próprios de eventos por segundo e de custo de armazenamento tomam a decisão certa na primeira tentativa. O controle GOV do Capítulo 15 fornece o modelo de maturidade para acompanhar a evolução do programa sobre a plataforma escolhida.