Laboratório de Cyber Security

LABORATÓRIO · BLUE TEAM · THREAT HUNTING

Laboratório de Cyber Security em Casa: Wazuh, Greenbone/OpenVAS e pfSense com Suricata + MITRE ATT&CK

Guia prático e gratuito para montar um mini-SOC, simular técnicas do MITRE ATT&CK e praticar detecção e threat hunting, com evidências documentadas.

Por RDS @RDSWEB · 07/10/2026 · leitura de ~14 min · nível intermediário

Ter a ferramenta instalada não é o mesmo que saber detectar. Este guia monta um laboratório isolado com quatro peças: Wazuh (SIEM/XDR), Greenbone/OpenVAS (vulnerabilidades), pfSense com Suricata (firewall e IDS) e Atomic Red Team (simulação de técnicas ATT&CK). O objetivo é fechar o ciclo completo: simular, detectar, investigar, corrigir e documentar.

4ferramentas gratuitas

10técnicas ATT&CK iniciais

R$ 0em licenças

14dias de roteiro

PONTOS DE ATENÇÃO

Ambiente isolado e seu. Use rede virtual sem rota para a rede doméstica ou de produção e tire snapshots antes de cada teste. As simulações executam comportamento real de ataque no sistema-alvo.

Autorização. Varrer ou atacar sistemas de terceiros sem autorização pode configurar invasão de dispositivo informático (Art. 154-A do Código Penal, Lei 12.737/2012). No laboratório, escaneie apenas as suas próprias VMs.

Dados. Não use dados pessoais reais no laboratório (LGPD). Use dados sintéticos.

Entenda os termos em linguagem simples

SIEM / XDR (Wazuh)

Central que recebe logs e eventos das máquinas, correlaciona e gera alertas. Os agentes instalados nos endpoints enviam os dados.

Gestão de vulnerabilidades (Greenbone/OpenVAS)

Varredura que procura falhas conhecidas (CVEs) e configurações fracas, com nota de severidade (CVSS) para priorizar a correção.

IDS/IPS (Suricata)

Inspeciona o tráfego de rede e compara com assinaturas de ataques. IDS apenas alerta; IPS pode bloquear.

MITRE ATT&CK

Catálogo público de táticas e técnicas reais de adversários, cada uma com um código (ex.: T1053.005). Serve de idioma comum entre quem ataca no teste e quem detecta.

Threat hunting

Busca proativa por sinais de ameaça que não geraram alerta, partindo de uma hipótese e consultando os dados.

Atomic Red Team

Biblioteca gratuita de pequenos testes, um por técnica ATT&CK, para verificar se a sua detecção funciona.

1. Arquitetura do laboratório

Duas redes virtuais separadas pelo pfSense: servidores e alvos de um lado, atacante e scanner do outro. Assim, todo o tráfego de teste atravessa o Suricata.

Figura 1. Topologia sugerida: o pfSense separa as redes e hospeda o Suricata.

Recursos das máquinas virtuais

VM	Função	vCPU	RAM	Disco
pfSense CE 2.9.0	Firewall, roteamento, Suricata	2	2 GB	20 GB
Wazuh (Ubuntu Server LTS)	Manager, Indexer, Dashboard	4	8 GB	50 GB
Greenbone (Ubuntu + Docker)	Scanner de vulnerabilidades	2 a 4	4 a 8 GB	40 GB
Windows 10/11	Alvo: Sysmon, agente, Atomic	2	4 GB	60 GB
Kali ou Ubuntu	Origem de tráfego	2	2 GB	25 GB

Wazuh: 4 vCPU, 8 GiB e 50 GB é o dimensionamento da documentação oficial para 1 a 25 agentes. Os demais valores são sugestões práticas, não requisitos oficiais.

PONTOS DE ATENÇÃO

Por que duas redes? Tráfego entre duas VMs no mesmo segmento não passa pelo pfSense, e o Suricata só enxerga o que atravessa a interface em que roda. Por isso o atacante e o scanner ficam em outra rede (OPT1).

Memória. Com todas as VMs ligadas são de 20 a 24 GB de RAM. Host de 32 GB é confortável. Em 16 GB, ligue por etapas (por exemplo, sem o Greenbone enquanto testa técnicas ATT&CK).

2. Wazuh: SIEM e XDR open source

O Wazuh recebe os eventos do Windows (via Sysmon), aplica regras e mostra cada alerta com o mapeamento para o MITRE ATT&CK.

1. VM do servidor. Ubuntu Server LTS com IP fixo 192.168.50.10 e gateway no pfSense (192.168.50.1).
2. Instalação all-in-one (manager, indexer e dashboard no mesmo host), comando da documentação oficial para a série 4.14:

   curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh && sudo bash ./wazuh-install.sh -a

   Confira a versão vigente no guia oficial antes de instalar.
3. Acesso. Abra https://192.168.50.10, usuário admin e a senha exibida no fim da instalação. O aviso de certificado é esperado. Para recuperar as senhas depois:

   sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

4. Agente no Windows. No dashboard, abra a tela de agentes e use Deploy new agent (o caminho do menu varia por versão). Execute o comando gerado no PowerShell como administrador e inicie o serviço do agente.
5. Sysmon no Windows com uma configuração que marque as regras com o ID da técnica (como a do projeto sysmon-modular):

   sysmon.exe -accepteula -i sysmonconfig.xml

6. Colete o canal do Sysmon. Em C:\Program Files (x86)\ossec-agent\ossec.conf, dentro de <ossec_config>:

   <localfile>
     <location>Microsoft-Windows-Sysmon/Operational</location>
     <log_format>eventchannel</log_format>
   </localfile>

   Reinicie o agente: Restart-Service -Name wazuh
7. Crie uma regra do laboratório no manager, em /var/ossec/etc/rules/local_rules.xml (modelo; valide antes de usar):

   <group name="windows,sysmon,">
     <rule id="100101" level="10">
       <if_group>sysmon_event1</if_group>
       <field name="win.eventdata.ruleName" type="pcre2">(?i)technique_id=T1053</field>
       <description>LAB: tarefa agendada criada (MITRE T1053.005)</description>
       <mitre><id>T1053.005</id></mitre>
     </rule>
   </group>

   Reinicie com systemctl restart wazuh-manager e teste com /var/ossec/bin/wazuh-logtest.

Recursos nativos para explorar

Recurso	Para que serve no laboratório
FIM (syscheck)	Detecta alteração em arquivos e chaves de registro críticas
SCA	Avalia a configuração do alvo contra políticas (inclui CIS)
Vulnerability Detection	Cruza software instalado nos agentes com bases de CVEs
Módulo MITRE ATT&CK	Agrupa alertas por tática e técnica (via tags nas regras)
Active Response	Executa uma ação automática ao disparar um alerta

PONTOS DE ATENÇÃO

Regra sem teste gera falso positivo ou não dispara. Valide cada regra nova com wazuh-logtest e confirme o nome do grupo e dos campos na sua versão. IDs de regras personalizadas devem ficar na faixa reservada, de 100000 a 120000.

3. Greenbone/OpenVAS: gestão de vulnerabilidades

OpenVAS é o scanner. O Greenbone Community Edition é o pacote completo (gerenciador, interface web, scanner e feeds). A forma mais simples de instalar é por containers.

1. VM Ubuntu com Docker e Docker Compose, IP 192.168.60.11, na rede LAN-ATK.
2. Baixe o arquivo compose (passos da documentação oficial do Greenbone Community Containers):

   export DOWNLOAD_DIR=$HOME/greenbone-community-edition && mkdir -p $DOWNLOAD_DIR
   curl -f -O -L https://greenbone.github.io/docs/latest/_static/compose.yaml --output-dir "$DOWNLOAD_DIR"

3. Baixe as imagens e suba os containers:

   docker compose -f $DOWNLOAD_DIR/compose.yaml pull
   docker compose -f $DOWNLOAD_DIR/compose.yaml up -d

4. Troque a senha padrão logo no início. O usuário inicial é admin com senha admin, o que é inseguro:

   docker compose -f $DOWNLOAD_DIR/compose.yaml \
       exec -u gvmd gvmd gvmd --user=admin --new-password='SuaSenhaForte'

5. Acesse a interface. O compose padrão publica a interface somente em 127.0.0.1. A partir do seu computador, use um túnel SSH:

   ssh -L 8443:127.0.0.1:443 usuario@192.168.60.11

   Depois abra https://localhost:8443.
6. Aguarde os feeds. Na primeira vez os dados de vulnerabilidades levam um bom tempo para carregar. Acompanhe os logs até aparecerem mensagens como "Finished loading VTs" (ospd-openvas) e "Updating VTs in database ... done" (gvmd):

   docker compose -f $DOWNLOAD_DIR/compose.yaml logs -f gvmd ospd-openvas

Fluxo de trabalho de uma varredura

#	Etapa
1	Cadastre o alvo (Configuration, Targets): somente o IP da VM Windows do laboratório
2	Opcional: crie uma credencial do Windows para varredura autenticada, que acha bem mais do que a varredura externa
3	Crie e execute a tarefa (Scans, Tasks) com a configuração "Full and fast"
4	Leia o relatório: ordene por severidade (CVSS) e qualidade da detecção (QoD)
5	Corrija ou mitigue, repita a varredura e compare antes e depois
6	Exporte o relatório e registre o hash (ver aba Hunting)

PONTOS DE ATENÇÃO

Varreduras são ruidosas: o Suricata vai gerar muitos alertas quando o Greenbone escanear o alvo. Isso é bom para estudo, pois mostra a diferença entre o que o scanner encontra e o que a rede detecta. Escaneie somente as VMs do laboratório.

4. pfSense com Suricata: firewall e IDS

O pfSense CE (versão 2.9.0, lançada em 20/08/2026) separa as redes e hospeda o Suricata, que inspeciona o tráfego e gera alertas por assinatura.

1. VM do pfSense com três placas: WAN (NAT do hipervisor), LAN (192.168.50.1/24) e OPT1 (192.168.60.1/24), cada uma em uma rede virtual interna distinta.
2. Regras de firewall. A interface OPT1 bloqueia tudo por padrão. Para o laboratório, crie em OPT1 uma regra permitindo origem OPT1 net para destino LAN net.
3. Instale o pacote. System, Package Manager, Available Packages, procure suricata e instale.
4. Configurações globais. Services, Suricata, Global Settings: marque a instalação das regras ETOpen (Emerging Threats), defina o intervalo de atualização e salve. Na aba Updates, force a primeira atualização.
5. Adicione as interfaces. Na aba Interfaces, adicione LAN e depois OPT1. Habilite cada uma e deixe Block Offenders desligado: comece em modo IDS, apenas alertando.
6. Escolha as categorias de regras (por exemplo: scan, exploit, malware, trojan, policy), salve e inicie a interface. Os alertas aparecem na aba Alerts.

Dois testes de sanidade

# a partir de uma VM da LAN, com acesso à internet pelo pfSense
curl http://testmynids.org/uid/index.html

# a partir do Kali, contra a VM Windows do laboratório
nmap -sS -sV 192.168.50.20

O primeiro costuma gerar um alerta do tipo "id check returned root" (SID 2100498), se o site de teste estiver acessível. O segundo deve gerar alertas da categoria ET SCAN; o conjunto exato depende das regras e da versão.

PONTOS DE ATENÇÃO

IDS antes de IPS. O modo IPS em linha (Inline) depende de placas compatíveis com netmap, e em máquinas virtuais pode derrubar a rede do laboratório. Comece em IDS e só depois teste o bloqueio.

WAN em rede privada. Se a WAN do pfSense recebe IP privado do NAT do hipervisor, desmarque "Block private networks" nessa interface, ou ele ficará sem internet.

Ruído. Ajuste as categorias e use suppress list para regras barulhentas. Menos alertas, e mais úteis, treinam melhor o olhar de analista.

Desafio opcional: encaminhe os logs do pfSense por syslog remoto ao Wazuh (porta 514/UDP, com <remote> do tipo syslog no manager) e escreva decoders e regras próprios. Exige validação com wazuh-logtest, e é um ótimo exercício de engenharia de detecção.

5. Simulando técnicas do MITRE ATT&CK

O Atomic Red Team executa pequenos testes por técnica. Para cada um, a pergunta é: o meu laboratório detectou?

1. Snapshot da VM Windows antes de qualquer teste.
2. Exclusão do antivírus apenas na VM do laboratório. O Defender pode apagar os arquivos dos testes. A documentação do projeto sugere excluir a pasta de instalação (C:\AtomicRedTeam) ou copiar apenas os testes que serão usados.
3. Instale o framework e os testes (PowerShell, comando da documentação oficial):

   IEX (IWR 'https://raw.githubusercontent.com/redcanaryco/invoke-atomicredteam/master/install-atomicredteam.ps1' -UseBasicParsing);
   Install-AtomicRedTeam -getAtomics

   A cada nova sessão do PowerShell:

   Import-Module "C:\AtomicRedTeam\invoke-atomicredteam\Invoke-AtomicRedTeam.psd1" -Force

4. Ciclo seguro de cada técnica (exemplo com T1053.005):

   Invoke-AtomicTest T1053.005 -ShowDetailsBrief
   Invoke-AtomicTest T1053.005 -CheckPrereqs
   Invoke-AtomicTest T1053.005 -GetPrereqs
   Invoke-AtomicTest T1053.005
   Invoke-AtomicTest T1053.005 -Cleanup

5. Verifique no Wazuh: o alerta apareceu? Em quanto tempo? Com a técnica certa? Registre o resultado.

Dez técnicas para começar

ID	Técnica	Telemetria esperada
T1053.005	Tarefa agendada	Sysmon evento 1 (schtasks); Security 4698, se a auditoria estiver ativa
T1218.010	Execução via Regsvr32	Sysmon evento 1 e conexões (evento 3)
T1518.001	Descoberta de software de segurança	Sysmon evento 1 (comandos de enumeração)
T1548.002	Bypass de UAC	Sysmon eventos 1 e 13 (registro)
T1574.001	Sequestro de DLL	Sysmon evento 7 (imagem carregada)
T1059.001	PowerShell	Sysmon evento 1; PowerShell 4104 (script block), se habilitado
T1136.001	Criar conta local	Security 4720
T1547.001	Chaves Run (persistência)	Sysmon evento 13 (valor de registro)
T1070.001	Limpar logs de eventos do Windows	Security 1102 / System 104
T1046	Descoberta de serviços de rede	Suricata: alertas ET SCAN (nmap do Kali)

As cinco primeiras (T1053.005, T1218.010, T1518.001, T1548.002 e T1574.001) são as emuladas no artigo do Wazuh sobre emulação de técnicas ATT&CK, que vale ler junto. Confira cada ID no site do MITRE ATT&CK e, no artigo, as diferenças entre IDs das regras e das técnicas.

Meça a cobertura

Pinte as técnicas no ATT&CK Navigator: verde para detectada, amarelo para detecção parcial e vermelho para não detectada. O vermelho é a sua lista de trabalho: escreva a regra, repita o teste e atualize o mapa.

PONTOS DE ATENÇÃO

Leia -ShowDetails antes de executar e sempre rode -Cleanup. Alguns testes alteram configurações do sistema. Nunca execute em máquina com dados reais, em produção ou em rede compartilhada.

6. Threat hunting e evidências

Hunting parte de uma hipótese: "se um adversário fez X, deixaria o rastro Y". Você procura o rastro nos dados, mesmo sem alerta.

Ciclo: hipótese, coleta de dados, consulta, pivô (a partir do achado, procurar o que veio antes e depois), documentação e, por fim, transformar o achado em regra de detecção.

Quatro hipóteses para praticar no Discover do Wazuh

Hipótese	Consulta de partida (DQL)
Persistência por tarefa agendada	data.win.eventdata.image : *schtasks.exe and data.win.eventdata.commandLine : *create*
PowerShell com comando codificado	data.win.eventdata.commandLine : *-enc* or data.win.eventdata.commandLine : *EncodedCommand*
Conta local criada	data.win.system.eventID : "4720"
Varredura de portas na rede	Aba Alerts do Suricata no pfSense, agrupando por IP de origem

Os campos são sensíveis a maiúsculas e minúsculas. Teste variações (por exemplo, /create e /Create) e confirme os nomes dos campos na sua versão.

Preserve as evidências como em um incidente real

Treine o hábito que faz diferença em investigação: exporte os alertas, gere o hash e registre data e responsável.

sha256sum alertas-lab-2026-10-07.json > alertas-lab-2026-10-07.sha256
date -u +"%Y-%m-%dT%H:%M:%SZ"  # registre o horário em UTC

Guarde, para cada teste: técnica, horário da execução, horário do alerta, regra disparada, captura de tela, arquivo exportado e hash. Esse é o início de uma cadeia de custódia do laboratório.

Métricas do laboratório

Métrica	Como medir
Cobertura ATT&CK	Técnicas detectadas dividido por técnicas emuladas
MTTD	Horário do alerta menos horário da execução (em UTC)
Falsos positivos	Alertas sem ameaça real por dia, após o ajuste das regras
Vulnerabilidades graves	Quantidade com CVSS de 7,0 ou mais, antes e depois da correção
Tempo de correção	Do relatório do Greenbone até a nova varredura limpa

7. Roteiro de 14 dias e portfólio

Dias	Entrega
1 e 2	Hipervisor, redes virtuais e pfSense funcionando (LAN e OPT1)
3 e 4	Wazuh instalado e dashboard acessível
5 e 6	Windows com agente e Sysmon enviando eventos
7	Greenbone com feeds carregados e primeira varredura
8 e 9	Suricata com regras ET Open e testes de sanidade
10 a 12	Atomic Red Team: dez técnicas, regras ajustadas e cobertura medida
13	Hunting com as quatro hipóteses e evidências com hash
14	Relatório final e publicação (blog e repositório)

Como documentar como projeto de portfólio

• README com objetivo, diagrama (Figura 1 adaptada) e versões usadas.
• Quadro de cobertura ATT&CK (Navigator) e tabela de MTTD por técnica.
• Relatório do Greenbone antes e depois, com as correções aplicadas.
• As regras personalizadas, com explicação e resultado do teste.
• Capturas de tela reais do seu laboratório e a data de cada execução.

PONTOS DE ATENÇÃO

Registre apenas o que você de fato executou e mediu. Cite o laboratório como projeto prático próprio, nunca como experiência em ambiente de produção. Em entrevista técnica, o que está documentado sustenta a conversa.

Perguntas frequentes

O Wazuh é SIEM ou EDR?

O Wazuh é uma plataforma open source que une funções de SIEM e XDR: coleta e correlaciona logs, monitora integridade de arquivos, avalia configurações (SCA) e detecta vulnerabilidades em endpoints por meio de agentes. Ele não substitui um EDR comercial, mas é ótimo para aprender detecção em endpoint.

Greenbone e OpenVAS são a mesma coisa?

OpenVAS é o scanner de vulnerabilidades. O Greenbone Community Edition é o conjunto completo que o envolve: gerenciador (gvmd), interface web (GSA), scanner e feeds de testes de vulnerabilidade.

Preciso de um computador potente para o laboratório?

O ideal é um host com 32 GB de RAM para manter todas as máquinas virtuais ligadas. Com 16 GB, ligue apenas as VMs necessárias a cada etapa, por exemplo sem o Greenbone enquanto testa técnicas do MITRE ATT&CK.

É legal executar o Atomic Red Team?

Em um ambiente próprio, isolado e autorizado, sim. Nunca execute em produção ou em sistemas de terceiros: a invasão de dispositivo informático é crime previsto no Art. 154-A do Código Penal (Lei 12.737/2012).

Como citar esse laboratório no currículo?

Como projeto prático ou laboratório próprio, com evidências verificáveis (relatório, repositório, quadro de cobertura ATT&CK), sem apresentá-lo como experiência em ambiente de produção.

Fontes consultadas

• Wazuh: guia de instalação rápida (quickstart)
• Wazuh: emulação de técnicas ATT&CK e detecção
• Greenbone: Community Edition com containers
• Atomic Red Team: instalação do Invoke-AtomicRedTeam
• Netgate: versões do pfSense e do FreeBSD
• MITRE ATT&CK

Precisa de uma investigação profissional?

Quando o problema é real e a decisão é de diretoria, o caminho é um diagnóstico estratégico: escopo, riscos, evidências e próximos passos, conduzidos com rigor técnico e jurídico.

Diagnóstico Estratégico pelo WhatsApp (47) 98861-8255

Investigação Defensiva

Inteligência Corporativa

Perícia Digital

Veja como a investigação defensiva produz provas sólidas

Patrocine o blog!
Apresente sua marca a um público de segurança da informação, direito e investigação.
Fale pelo WhatsApp

RDS ; Professor de Open Source Intelligence, entusiasta da Segurança da Informação e datascience
RDS @RDSWEB · LinkedIn · Facebook · Instagram

Aviso: este conteúdo foi gerado com apoio de inteligência artificial, com base em pesquisa online de documentação oficial e de artigos técnicos de terceiros. Não nos responsabilizamos pela exatidão de fontes externas; confira sempre a documentação vigente de cada ferramenta. Nada neste artigo tem finalidade ofensiva ou instrucional para reproduzir ataques: o propósito é estritamente defensivo e educacional, apoiando profissionais, empresas e equipes de segurança na atualização sobre o modus operandi real das ameaças e no fortalecimento de uma cultura de boas práticas de segurança da informação, prevenção e resposta a incidentes.