Sysmon: Telemetria de Endpoint no Windows

O Windows Event Log conta que um processo arrancou, e o Sysmon conta com que linha de comandos, que hash, que pai, que rede, que DLL. É o serviço de telemetria gratuito da Sysinternals (v15.22) que corre como driver no Windows e gera eventos detalhados para o Event Log — a matéria-prima que o Wazuh e o Microsoft Sentinel consomem para detectar o que o log de Segurança não mostra: execução por scripts ofuscados, ligações de processos que não deviam ligar, e DLLs carregadas de onde não deviam. Este guia instala, configura com o template comunitário da SwiftOnSecurity, e liga os eventos ao Wazuh.

Neste artigo

1. O que o Sysmon regista
2. Instalar com um ficheiro de configuração
3. Os três eventos essenciais: 1, 3, 11
4. Configuração da SwiftOnSecurity
5. Integrar com o Wazuh
6. Ruído e tuning

1. O que o Sysmon regista

O Sysmon é um serviço e driver de modo kernel que gera eventos estruturados no canal Applications and Services Logs/Microsoft/Windows/Sysmon/Operational (no Event Viewer), com timestamps em UTC. Os eventos de versões antigas (pré-Vista) vão para o log System. Instalar e desinstalar não exige reinício.

O serviço cobre hoje 29 tipos de evento (Event ID 1 a 29 na v15.22): criação e terminação de processos, ligações de rede, criação e modificação de ficheiros, acesso ao registry, DLLs carregadas, criação de named streams, alterações ao clipboard, e mais. Filtra-se tudo por regras de inclusão/exclusão num XML — é o ficheiro de configuração que decide o ruído.

A documentação é explícita no papel: o Sysmon complementa o logging nativo do Windows, não o substitui — o log de Segurança (logins, grupos, políticas) continua a ser imprescindível para investigações.

2. Instalar com um ficheiro de configuração

O pacote vem em ZIP da página oficial da Sysinternals (Sysmon.zip). Os comandos:

Sem ficheiro de configuração, sysmon -accepteula -i instala com o default — processos com hash SHA1, sem monitorização de rede — o que serve para começar a ver mas não para produção. O -accepteula salta a aceitação manual da EULA. Nem instalação nem desinstalação pedem reboot.

3. Os três eventos essenciais: 1, 3, 11

Dos 29 tipos, três concentram o valor prático de um deployment inicial:

• Event ID 1 — Process creation. Regista cada novo processo com a linha de comando completa, o processo pai, o utilizador, os hashes (SHA1, e na config da SwiftOnSecurity, MD5/SHA256/IMPHASH). É o evento que revela cmd.exe a correr um PowerShell ofuscado lançado por macro do Word — a cadeia de ataque visível num só evento.
• Event ID 3 — Network connection. Ligações TCP/UDP por máquina, cada uma ligada ao processo pelo ProcessId — a saída para C2, os beacons de um processo estranho para a porta 443 às 3h. Desactivado por omissão — só corre com uma configuração que o inclua, o que já diz porque é que o default não serve.
• Event ID 11 — FileCreate. Criação e sobre-escrita de ficheiros, com a utilidade principal nas localizações de autostart (pasta Startup, chaves Run do registry monitoradas pelo Event ID 12/13) e ficheiros temporários executáveis.

Os restantes ID cobrem casos mais específicos — Image loading (7), registry (12-14), DNS query (22), clipboard (24) — e activam-se conforme a superfície a vigiar.

4. Configuração da SwiftOnSecurity

Escrever as regras XPath à mão é o caminho mais longo. O template comunitário da SwiftOnSecurity (sysmonconfig-export.xml) é o ponto de partida de facto: cada linha comentada, secções por área, e uma base de exclusões testada — “a config funciona como tutorial de Sysmon”, nas palavras do próprio README. O repositório traz o XML pronto a descarregar:

A alternativa mais granular é o sysmon-modular de Olaf Hartong — um superset por fases MITRE. Para começar, o SwiftOnSecurity chega e documenta o caminho.

Os eventos chegam em Event Viewer → Applications and Services Logs → Microsoft → Windows → Sysmon → Operational, consultáveis com o Event Viewer ou por PowerShell:

5. Integrar com o Wazuh

O agente Wazuh para Windows recolhe o canal Sysmon nativamente — está na tabela de canais suportados da documentação (log collection → configuration), com o canal Microsoft-Windows-Sysmon/Operational. Por omissão, o agente Wazuh só monitoriza os canais System, Application e Security — o canal Sysmon precisa de um bloco <localfile> no ossec.conf com o <location>Microsoft-Windows-Sysmon/Operational</location> e formato eventchannel, e os eventos chegam ao manager, onde os decoders e regras do Wazuh os classificam — o blog oficial da Wazuh tem o guia de detecção com Sysmon completo.

No Microsoft Sentinel, o conector Windows Security Events via AMA (Azure Monitor Agent) recolhe o mesmo canal — os eventos Sysmon, configurados como canal custom na DCR, chegam à tabela WindowsEvent (a ingestão para SecurityEvent é específica dos conjuntos de eventos de auditoria de segurança). Em ambos os casos, o custo de ingestão cresce com o ruído — daí a configuração importar mais que o agente.

6. Ruído e tuning

Uma configuração sem filtros gera eventos por cada processo do browser, cada update do Teams, cada script do Intune. A configuração SwiftOnSecurity exclui por defeito os padrões legítimos mais ruidosos (Chrome, Office, Windows Update) e inclui os comportamentos suspeitos (scripts em pastas temporárias, execução de certutil com download, PSExec em contexto de serviço).

O tuning corre no ficheiro: cada <Rule name="..." groupRelation="or"> tem onmatch="exclude" ou "include", e a recarga é automática — a documentação destaca que o Sysmon recarrega a configuração quando muda no registry. O comando sysmon -c config.xml reconfigura sem reboot, e sysmon -s mostra o schema validador que evita erros de XML nas edições.

Erros Comuns

Checklist

• [ ] Sysmon v15+ descarregado da Sysinternals
• [ ] Configuração SwiftOnSecurity aplicada (sysmon -accepteula -i config.xml)
• [ ] Event ID 1, 3 e 11 a chegar ao canal Operational
• [ ] Canal Microsoft-Windows-Sysmon/Operational recolhido pelo agente Wazuh (ou AMA/Sentinel)
• [ ] Exclusões de ruído revistas para as aplicações da PME
• [ ] Disco com espaço para o volume de eventos
• [ ] Alertas de processos suspeitos no SIEM testados

Artigos Relacionados

• Regras ASR no Defender: do Modo Auditoria ao Enforcement — a defesa activa que complementa a telemetria
• Microsoft Defender for Endpoint: Implementação e Configuração — a telemetria de detecção no endpoint
• Dia 28: Auditoria, Registos e Alertas — Microsoft 365 — o consumidor cloud dos registos centralizados

Fontes Oficiais

• Sysmon — Microsoft Sysinternals
• Using Wazuh to monitor Sysmon events — Wazuh blog
• Log data collection configuration — Wazuh documentation
• sysmon-config — SwiftOnSecurity
• sysmon-modular — olafhartong