Windows Server 2025
Standard com Desktop Experience, avaliação gratuita de 180 dias. VM no VMware Workstation com 4GB RAM, 60GB disco NVMe, UEFI + Secure Boot. IP estático 10.10.10.40 na LAN do pfSense.
Blue Team • Sysmon • SIEM • Red Team vs Blue Team
Provisionamento de Windows Server 2025 com Sysmon, auditoria avançada de processo e PowerShell logging — integrado ao Wazuh SIEM. Dois exercícios reais de Red Team vs Blue Team: exploração de Metasploitable2 via CVE-2007-2447 e SQL Injection/XSS no OWASP Juice Shop, com detecção validada no Suricata e no dashboard.
Topologia
Este laboratório foi executado em ambiente local, controlado e autorizado. Endereços IP, hostnames, usuários, comandos e evidências exibidos pertencem ao ambiente de estudo ou foram anonimizados. Nenhuma credencial real, token, chave privada ou dado sensível deve ser publicado.
Índice
Sobre o laboratório
A maioria das detecções de SOC no mercado real — e a maioria das regras prontas do Wazuh e do framework Sigma — é voltada a Windows Event Log, Sysmon e PowerShell logging. Um ambiente só Linux, por mais completo que seja, deixa esse eixo de visibilidade em aberto.
Este laboratório fecha essa lacuna: um Windows Server 2025 com telemetria de host completa (Sysmon, Event ID 4688 com linha de comando, script block logging do PowerShell), integrado ao mesmo Wazuh Manager já em produção no lab. O resultado é um pipeline de detecção que cobre tanto o host Windows quanto o tráfego de rede capturado pelo Suricata — e foi validado com ataques reais, não cenários simulados.
Especificações
Standard com Desktop Experience, avaliação gratuita de 180 dias. VM no VMware Workstation com 4GB RAM, 60GB disco NVMe, UEFI + Secure Boot. IP estático 10.10.10.40 na LAN do pfSense.
Instalado com a configuração de referência da comunidade (SwiftOnSecurity). Captura criação de processos, conexões de rede, criação de arquivos e alterações de registro com hashes e processo pai completo.
Três políticas habilitadas via GPO: linha de comando completa no Event ID 4688, auditoria de criação de processo (Success), e PowerShell Script Block Logging (Event ID 4104 com conteúdo real de scripts).
Agente instalado e registrado no Manager existente (10.10.10.10). Configurado para monitorar os canais Sysmon/Operational e PowerShell/Operational além dos canais padrão (Application, Security, System).
Processo de implementação
Cada etapa foi executada, validada e documentada antes de avançar. Dois problemas reais de infraestrutura foram encontrados e resolvidos durante o processo — registrados aqui como parte do aprendizado.
Download do ISO via Microsoft Evaluation Center, criação da VM com UEFI + Secure Boot, rede em VMnet1 (mesma LAN do pfSense, Kali e Wazuh). Instalação limpa do Windows Server 2025 Standard com Desktop Experience.
IP estático aplicado via PowerShell após falha silenciosa da GUI (DHCP continuou ativo mesmo após configuração manual pelo Painel de Controle). Diagnóstico com Get-NetIPInterface confirmou a causa raiz.
Sysmon instalado com config da SwiftOnSecurity. Três políticas de auditoria habilitadas via GPO: linha de comando no 4688, Auditar Criação de Processo (Êxito) e PowerShell Script Block Logging. Validado com Event IDs 4688 e 4104 reais.
Agente instalado via MSI gerado pelo dashboard. Canal Sysmon/Operational e PowerShell/Operational adicionados ao ossec.conf. Agente registrado com status Active no Manager e eventos do Sysmon visíveis no dashboard.
Cobertura de telemetria
Com Sysmon + auditoria avançada + PowerShell logging, o host Windows passa a gerar uma telemetria bem mais rica do que a configuração padrão. Os três canais se complementam: Sysmon tem mais contexto por evento (hash, processo pai detalhado), o Event ID 4688 é nativo do SO sem dependência de ferramenta extra, e o 4104 captura o conteúdo real de scripts PowerShell — inclusive após deofuscação em memória.
Criação de processos com hash SHA256 e processo pai completo (ID 1), conexões de rede com IP/porta de destino (ID 3), criação de arquivos (ID 11) e alterações de registro (ID 13). Base do framework de detecção Sigma.
Criação de processo com a linha de comando completa no campo Process Command Line — preenchido somente com a política de auditoria avançada ativa. Detecta execuções suspeitas como cmd.exe /c whoami ou download via PowerShell.
Conteúdo completo de blocos de script PowerShell executados, incluindo scripts deofuscados em memória. Essencial para detectar técnicas como download cradles, encoded commands e living-off-the-land.
Integração com Wazuh
O Sysmon registra eventos em Microsoft-Windows-Sysmon/Operational. As políticas de auditoria alimentam o Security log (4688) e o PowerShell/Operational (4104).
O bloco <localfile><log_format>eventchannel</log_format> no ossec.conf instrui o agente a ler os canais configurados e enviar ao Manager via TCP 1514.
O Manager aplica decoders nativos de Windows (campos data.win.eventdata.*) e regras de detecção — incluindo mapeamento para MITRE ATT&CK.
Eventos visíveis no Threat Hunting com filtros por agent.name: win-srv01, pesquisáveis por Event ID, linha de comando ou hash de processo.
Red Team vs Blue Team
O objetivo foi sair de "telemetria passiva" para um ciclo completo de detecção: configurar o sensor, atacar de propósito, e validar — ou identificar a ausência de — detecção real no SIEM. Dois alvos foram utilizados, cada um expondo uma camada diferente do pipeline de detecção.
Exercício 1
VM Metasploitable2 provisionada na mesma VMnet1 (10.10.10.30).
Reconhecimento com nmap revelou 29 portas abertas incluindo Samba 3.X nas portas 139/445.
nmap -sV -p- contra o alvo. 29 serviços identificados incluindo vsftpd 2.3.4, Samba 3.X, UnrealIRCd e distccd — todos com vulnerabilidades conhecidas.
Módulo Metasploit exploit/multi/samba/usermap_script. Shell reversa aberta na porta 4444. Confirmação: whoami → root, uid=0(root).
Após correção da interface de captura (eth1 → eth0), Suricata detectou: reconhecimento (POSSBL PORT SCAN NMAP -sA) e exploração (POSSBL SCAN SHELL M-SPLOIT TCP, severity 1, categoria "Network Trojan detected").
Alerta real no eve.json
{
"event_type": "alert",
"src_ip": "10.10.10.30",
"dest_ip": "10.10.10.20",
"dest_port": 4444,
"alert": {
"signature": "POSSBL SCAN SHELL M-SPLOIT TCP",
"category": "A Network Trojan was detected",
"severity": 1,
"signature_id": 3400020
}
}
Exercício 2
Juice Shop rodando via Docker no Kali (10.10.10.20:3000).
Ataques executados a partir do navegador do Windows Server, garantindo que o tráfego
atravessasse a rede física e fosse capturável pelo Suricata.
Payload ' OR 1=1-- no campo de email do login. Acesso ao administrador sem senha. Desafio "Login Admin" resolvido. Tráfego via POST /rest/user/login com body JSON.
Payload <img src=x onerror="alert('XSS')"> na busca. Desafio "DOM XSS" resolvido. Mas o parâmetro nunca trafegou pela rede — /rest/products/search?q= sempre chegou vazio ao servidor.
ET Open tem 7104 regras de web-application-attack, mas escritas para stacks PHP/GET — não para APIs JSON modernas. Regra customizada criada com http.request_body para inspecionar corpo de POST.
Regra customizada — local.rules
alert http any any -> any 3000 ( msg:"LOCAL SQLi Attempt - OR 1=1 in HTTP Body"; flow:to_server,established; http.request_body; content:"OR 1"; nocase; classtype:web-application-attack; sid:9000001; rev:1; )
Gap analysis — visibilidade por tipo de ataque
| Tipo de ataque | Trafega pela rede? | ET Open detecta? | Regra customizada? |
|---|---|---|---|
| SQLi em query string (GET) | ✅ Sim | ✅ Sim (ET Open) | — |
| SQLi em body JSON (POST API) | ✅ Sim | ❌ Não (gap real) | ✅ SID 9000001 |
| XSS Refletido/Armazenado | ✅ Sim | ⚠️ Parcial | ✅ SID 9000002 |
| DOM XSS puro (client-side) | ❌ Não | ❌ Impossível | ❌ Impossível por design |
DOM XSS puro é processado inteiramente no frontend (Angular/React roteamento baseado em hash). O parâmetro nunca sai do navegador como requisição HTTP — nenhuma ferramenta de inspeção de rede pode detectar algo que não trafega. Controles adequados: CSP headers, WAF com inspeção JS, RASP.
Tuning de regras
Durante a operação do lab, dois problemas reais de infraestrutura foram identificados e corrigidos — registrados aqui como exercício genuíno de troubleshooting de SOC.
O Suricata estava com af-packet: interface: eth1 — a rede secundária do Kali (10.10.20.0/24), não a LAN do lab (eth0, 10.10.10.0/24). Ataques contra Metasploitable2 não apareciam no SIEM. Diagnóstico pelo suricata.yaml, correção e revalidação com reteste do ataque.
Regra nativa 92205 (nível 9) disparou para uma execução legítima do módulo SCA do próprio Wazuh — SecEdit.exe exportando política de segurança local. Falso positivo confirmado por análise de parentImage, currentDirectory e hash do binário. Regra de exceção criada no local_rules.xml com nível rebaixado para 3.
Competências desenvolvidas
Configuração de Sysmon com config da comunidade, habilitação de políticas de auditoria avançada via GPO e PowerShell Script Block Logging — base da detecção de endpoint em ambientes Windows corporativos.
Deploy de agente Wazuh em Windows Server, configuração de canais de evento customizados no ossec.conf e validação de ingestão no dashboard. Tuning de regras com criação de exceção no local_rules.xml.
Reconhecimento com nmap, exploração de CVE via Metasploit Framework, obtenção de shell reversa. SQL Injection e DOM XSS contra aplicação web moderna. Cadeia completa de comprometimento documentada.
Correlação de eventos de host (Sysmon) e rede (Suricata) para reconstrução de ataque no SIEM. Análise de falso positivo com identificação de processo pai, hash e integridade. Gap analysis de visibilidade.
Criação de regras Suricata customizadas para cobrir gap real do ET Open contra APIs JSON modernas. Uso de http.request_body e pcre para inspecção de body de POST e URI.
Diagnóstico de IP estático não persistido (GUI vs PowerShell), identificação de sensor de rede mal posicionado (interface errada no af-packet) e correção com revalidação ativa — processo documentado como lição aprendida.
Resultados
Evidências
Conclusão
Este laboratório fechou o eixo Windows do ambiente de SOC — adicionando a telemetria de host mais relevante para o mercado ao pipeline já existente de Suricata e Wazuh. Os exercícios de Red Team não foram apenas execução de exploits: cada ataque foi acompanhado de análise de detecção, diagnóstico de gaps e, quando possível, criação de cobertura customizada. O resultado é um ciclo completo de detecção, resposta e documentação — do ataque ao alerta no SIEM.
Download do ISO via Microsoft Evaluation Center — avaliação gratuita de 180 dias, sem necessidade de product key.
Parâmetros da VM no VMware Workstation:
vCPU: 2 | RAM: 4GB | Disco: 60GB NVMe (thin) Firmware: UEFI + Secure Boot Rede: Custom → VMnet1 (LAN do pfSense) Edição: Standard com Desktop Experience
⚠️ O wizard do VMware só oferece Bridged/NAT/Host-only durante a criação. A opção Custom: VMnet1 só aparece em Edit VM Settings → Network Adapter — ajuste obrigatório antes do primeiro boot.
A configuração via GUI (Painel de Controle → Propriedades do adaptador) foi aplicada, mas o DHCP continuou ativo silenciosamente. Diagnóstico:
Get-NetIPInterface -InterfaceAlias "Ethernet0" -AddressFamily IPv4 ` | Select-Object InterfaceAlias, Dhcp # Resultado: Dhcp → Enabled ← nunca desabilitado
Correção via PowerShell (reproduzível e auditável):
Remove-NetIPAddress -InterfaceAlias "Ethernet0" -Confirm:$false Remove-NetRoute -InterfaceAlias "Ethernet0" -Confirm:$false -ErrorAction SilentlyContinue Set-NetIPInterface -InterfaceAlias "Ethernet0" -Dhcp Disabled New-NetIPAddress -InterfaceAlias "Ethernet0" -IPAddress 10.10.10.40 -PrefixLength 24 -DefaultGateway 10.10.10.1 Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 10.10.10.1
Instalação do Sysmon com a config da SwiftOnSecurity:
.\Sysmon64.exe -i sysmonconfig-export.xml -accepteula Get-Service sysmon64 # Status: Running
Três políticas habilitadas via gpedit.msc e aplicadas com gpupdate /force:
Comando gerado pelo dashboard (Agents Management → Deploy new agent → Windows):
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.14.5-1.msi ` -OutFile $env:tmp\wazuh-agent.msi msiexec.exe /i $env:tmp\wazuh-agent.msi /q ` WAZUH_MANAGER='10.10.10.10' ` WAZUH_AGENT_NAME='win-srv01' NET START WazuhSvc
Blocos adicionados ao ossec.conf para monitorar Sysmon e PowerShell:
<localfile> <location>Microsoft-Windows-Sysmon/Operational</location> <log_format>eventchannel</log_format> </localfile> <localfile> <location>Microsoft-Windows-PowerShell/Operational</location> <log_format>eventchannel</log_format> </localfile>