SOC Home Lab

Problema

Threat hunting em AD requer prática em um ambiente onde você controla tanto o atacante quanto o defensor. Labs comerciais são caros e engessados; screenshots de blog post são superficiais.

Eu queria um ambiente onde pudesse: rodar um Kerberoast real, ver o Event 4769 chegar no Wazuh, escrever a regra Sigma, validar contra falso-positivo, e medir o MTTD de ponta a ponta. Tudo isolado da minha rede doméstica, zero custo recorrente, e — crítico — zero dependência de dados de cliente. Tudo sintético, tudo fictício, tudo RFC5737.

Você não aprende detection engineering lendo blog posts. Aprende fazendo a detecção falhar três vezes e descobrindo por quê.

Arquitetura

Um host Proxmox hospeda 8 VMs: um domínio AD completo (DC + workstations), firewall pfSense com Suricata, Wazuh manager + OpenSearch, e uma VM Kali para simular o atacante. Todo o tráfego passa pelo pfSense para garantir visibilidade de rede.

// IPs RFC5737 · hostnames fictícios · zero referência a infraestrutura real

Implementação

Stack escolhida por custo zero e extensibilidade — cada componente pode ser substituído pelo equivalente corporativo sem reescrever as regras.

Regras Sigma vivem em um repositório Git público. CI converte YAML Sigma → regras Wazuh via sigma-cli. Cada PR roda testes de unidade contra logs sintéticos antes de mergear.

Detecções

Cinco detecções notáveis implementadas no lab. Cada uma nasceu reproduzindo um ataque real com ferramentas públicas, capturando os eventos crus, e escrevendo a regra do zero.

# TGS request with RC4 encryption for a service account
title: Suspicious TGS Request (Kerberoasting)
id: a7f4b8c1-9d2e-4c9f-8a1b-3e5d7f9a2c4d
status: stable
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryption: '0x17'
    ServiceName|endswith: '$'
  condition: selection
level: high
tags: [attack.credential_access, attack.t1558.003]

# Directory replication rights used from non-DC host
title: DCSync via Replication Rights
logsource: { product: windows, service: security }
detection:
  selection:
    EventID: 4662
    Properties|contains:
      - '1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes
      - '1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'  # DS-Replication-Get-Changes-All
  filter_dc:
    SubjectUserName|endswith: '$'
  condition: selection and not filter_dc
level: critical
tags: [attack.credential_access, attack.t1003.006]

Métricas

Números do lab nos últimos 30 dias. Ambiente de research — não comparáveis a um SOC corporativo (volume, variedade de endpoints, e skill do atacante são todos limitados).

Lições aprendidas

O que funcionou — e o que não funcionou. Honesto.

• Funcionou: versionar regras Sigma em Git com CI. Regra sem teste é regra que vira falso positivo em produção.
• Funcionou: separar zona de ataque em VLAN isolada no pfSense. Evita que Rubeus escape para a rede doméstica.
• Não funcionou (v1): tentar replicar telemetria de endpoint sem Sysmon. Event log nativo do Windows é insuficiente — Sysmon é negociável apenas em ambientes com EDR pago.
• Não funcionou (v1): Wazuh agent em modo "full events" — OpenSearch quebrou a ingestão em >500k eventos/dia. Solução: filtering na origem via Wazuh ruleset.
• Aprendizado: detection engineering é 20% escrever regra, 80% triagem de FP. Meu primeiro Kerberoast rule quebrou em qualquer backup do AD — filtro de máquinas de backup resolveu.
• Aprendizado: escrever a regra depois de rodar o ataque, não antes. A documentação do ATT&CK é ponto de partida, não ponto de chegada.

Links & repos

Parte das regras está pública. Comentários e PRs bem-vindos.