Blue Team • Sysmon • SIEM • Red Team vs Blue Team

Windows Server 2025 + Sysmon Telemetria avançada e detecção real de ataques

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.

Fluxo do laboratório

Windows Server 2025 — Sysmon + Wazuh Agent Sysmon / Event Log / PowerShell Operational Wazuh Agent → Manager (10.10.10.10) Suricata (Kali) → eve.json Wazuh Dashboard — Threat Hunting

Aviso sobre o ambiente

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.

Navegue pelo conteúdo desta documentação.

Por que Windows Server no lab de SOC.

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.

Ambiente técnico do laboratório.

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.

WS 2025 Standard VMware Workstation UEFI VMnet1

Sysmon

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.

Sysmon64 SwiftOnSecurity config Event ID 1/3/11/13

Auditoria avançada

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

Event ID 4688 Event ID 4104 gpedit.msc gpupdate /force

Wazuh Agent 4.14.5

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

Wazuh 4.14.5 ossec.conf eventchannel

Do download ao endpoint monitorado.

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.

Concluído

Provisionamento da VM

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.

UEFISecure BootVMnet1Desktop Experience
Concluído

Configuração de rede estática

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.

New-NetIPAddressSet-NetIPInterface10.10.10.40/24
Concluído

Sysmon + Auditoria avançada

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.

Sysmon64.exe -igpedit.mscgpupdate /force
Concluído

Agente Wazuh + ossec.conf

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.

wazuh-agent-4.14.5.msiossec.confeventchannel

O que este endpoint gera de visibilidade.

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.

Sysmon (Event IDs 1, 3, 11, 13)

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.

EID 1 — ProcessoEID 3 — RedeEID 11 — ArquivoEID 13 — Registry

Event ID 4688 — Linha de comando

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.

Security LogEID 4688CommandLine completo

Event ID 4104 — Script Block

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.

PowerShell OperationalEID 4104Script Block

Como os eventos do Windows chegam ao SIEM.

Sysmon e Windows Event Log geram eventos

O Sysmon registra eventos em Microsoft-Windows-Sysmon/Operational. As políticas de auditoria alimentam o Security log (4688) e o PowerShell/Operational (4104).

Agente Wazuh coleta via eventchannel

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.

Wazuh Manager decodifica e correlaciona

O Manager aplica decoders nativos de Windows (campos data.win.eventdata.*) e regras de detecção — incluindo mapeamento para MITRE ATT&CK.

Dashboard — Threat Hunting

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.

Dois ataques reais. Detecção validada.

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.

Metasploitable2 — CVE-2007-2447 (Samba usermap_script)

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.

Reconhecimento

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.

nmap -sV -p-29 portas abertasSamba 3.X

Exploração — acesso root

Módulo Metasploit exploit/multi/samba/usermap_script. Shell reversa aberta na porta 4444. Confirmação: whoami → root, uid=0(root).

CVE-2007-2447Shell reversaPorta 4444root

Detecção — Suricata

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").

SID 3400020Severity 186601 no Wazuh
{
  "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
  }
}

OWASP Juice Shop — SQLi, DOM XSS e gap de detecção

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.

SQL Injection — bypass de login

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.

SQLiPOST bodyLogin Admin

DOM XSS — limite do NIDS

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.

DOM XSSClient-sideSem tráfego de rede

Regra customizada criada

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.

SID 9000001http.request_bodylocal.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;
)
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.

Problema real encontrado e resolvido.

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.

Sensor na interface errada

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.

eth1 → eth0suricata.yamlaf-packet

Falso positivo — SCA/SecEdit (rule 92205)

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.

Rule ID 100205local_rules.xmlif_sid: 92205

O que este laboratório construiu na prática.

O que foi entregue neste laboratório.

3Canais de telemetria Windows
2Ataques reais executados
2Regras customizadas criadas
100%Detecção validada no SIEM

Registros do laboratório.

2 agentes Active no dashboard 3.091 eventos capturados Shell reversa Metasploit detectada SQLi detectado por regra customizada
Agentes Wazuh ativos
Wazuh Endpoints — kali-linux (ID 001) e win-srv01 (ID 002) ambos Active.
Threat Hunting win-srv01
Threat Hunting — 3.091 eventos do win-srv01 nos últimos 7 dias.
Shell reversa Metasploit detectada
Red Team — POSSBL SCAN SHELL M-SPLOIT TCP (SID 3400020) detectado.
SQLi detectado por regra customizada
Regra customizada SID 9000001 — LOCAL SQLi Attempt detectado no Juice Shop.

Endpoint monitorado. Ataques detectados. Pipeline validado.

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.

Provisionamento da VM

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.

Configuração de rede estática

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

Sysmon + Auditoria avançada

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:

Agente Wazuh + ossec.conf

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>