O log de segurança padrão do Windows responde quem autenticou e qual objeto mudou, mas não mostra a linha de comando que executou o processo suspeito, não liga uma conexão de rede ao binário que a originou e não expõe injeção de código entre processos. Para equipes que operam detecção em endpoints Windows, essa lacuna aparece justamente durante a investigação de um incidente. O System Monitor (Sysmon), serviço e driver mantidos pela Microsoft dentro do Sysinternals, permanece residente entre reinicializações e grava no log de eventos do Windows a telemetria que falta: execução, rede e arquivo, com contexto por processo. A ação prioritária é implantá-lo com um perfil filtrado, medir o volume gerado em máquinas representativas e só então estender ao parque inteiro — habilitar todos os eventos de uma vez é a receita para pagar ingestão sem ganhar detecção.
O que o Sysmon registra
A documentação oficial descreve o objetivo com precisão: a ferramenta fornece informações detalhadas sobre criação de processos, conexões de rede e alterações de data de criação de arquivos. Cada evento carrega contexto que o log nativo não tem: a linha de comando completa do processo e do processo pai, hashes do binário (SHA1, MD5, SHA256 ou IMPHASH, combináveis no mesmo evento), um GUID de processo que permite correlacionar eventos mesmo quando o Windows reutiliza identificadores de processo e um GUID de sessão que amarra eventos do mesmo logon. O evento de criação de processo (ID 1) é o mais valioso e o mais barato: sem ele, boa parte da investigação de execução se resume a suposição.
Há três limites que o time precisa internalizar antes de prometer cobertura. Primeiro, o Sysmon não analisa o que registra: a detecção continua morando no SIEM ou na regra que a equipe escrever. Segundo, ele não se esconde do atacante: quem tem privilégio no host enxerga o driver e o arquivo de configuração, e o próprio projeto sysmon-modular trata a sabotagem à ferramenta como tema de manutenção. Terceiro, ele é complemento, não substituto: eventos de autenticação e de auditoria nativa seguem indispensáveis para reconstruir uma intrusão. Para o lado Linux, o portal já detalhou a lógica equivalente com auditd sem ruído, e o princípio de filtrar na origem é o mesmo.
Cobertura sem afogar o SIEM
O erro clássico é ativar tudo e descobrir o custo na fatura de ingestão. A própria Microsoft avisa que monitorar todos os eventos de carregamento de módulo gera um volume significativo de logs — o evento 7 vem desativado por padrão por esse motivo. O evento de acesso a processo (ID 10), que expõe ferramentas lendo a memória de processos sensíveis como o LSASS, cai no mesmo problema: utilitários de diagnóstico abrem processos repetidamente e enchem o canal quando não há exclusões. Já a conexão de rede (ID 3), que vincula IP e porta ao processo de origem, também vem desativada por padrão e pode inundar estações de trabalho com tráfego legítimo de navegadores e atualizadores. A regra prática é incluir o que tem valor de detecção comprovado e excluir o ruído conhecido na origem, antes do transporte.
O mantenedor do modelo de configuração mais usado resume a etapa que quase todo time pula: observar o resultado no próprio ambiente e excluir as ações do antivírus, que de outra forma enchem os logs com informação inútil. Filtrar no XML do Sysmon, com as condições is, contains e excludes, reduz simultaneamente custo de rede, ingestão e armazenamento — e preserva a exclusão mesmo se o agente de coleta mudar.
| Evento | Valor detetivo | Risco de ruído |
|---|---|---|
| 1 — criação de processo | Linha de comando completa, hashes, processo pai | Baixo; base de qualquer implantação |
| 3 — conexão de rede | Liga IP e porta ao processo de origem | Alto em estações; ativar por perfil de máquina |
| 7 — carregamento de módulo | DLL com assinatura e hash | Muito alto; só com lista de inclusão |
| 10 — acesso a processo | Leitura de memória do LSASS e injeção | Alto sem excluir utilitários de diagnóstico |
| 11 — criação de arquivo | Pastas de inicialização e downloads | Moderado com caminhos filtrados |
| 13 — valor de registro | Chaves de persistência | Moderado com chaves-alvo |
| 17 e 18 — pipes nomeados | Comunicação usada por malware | Baixo com regras de inclusão |
Perfis prontos e personalização
Duas bases públicas evitam começar do zero. O sysmon-config é um arquivo comentado linha por linha, pensado como ponto de partida e tutorial ao mesmo tempo; o texto do projeto é explícito em que cada ambiente precisa observar o resultado e personalizar antes de implantar em larga escala, e recomenda instalar software no escopo da máquina, e não dentro de C:\Users, para reduzir monitoramento desnecessário. Já o sysmon-modular divide a configuração em módulos XML por tipo de evento e distribui perfis gerados para as versões 15.21, 14.16, 13.34 e 12.03 do Sysmon, com variantes balanceada, com arquivamento de exclusão de arquivos e uma opção pensada para complementar o Microsoft Defender for Endpoint sem duplicar o que a plataforma já coleta.
Para decisões de cobertura, o sysmon-modular também publica uma camada do ATT&CK Navigator derivada do perfil balanceado: ela mostra, técnica por técnica, o que a configuração enxerga. Cobertura declarada, porém, não é cobertura medida — vale cruzar essa camada com as técnicas observadas nos exercícios de simulação da própria equipe, em vez de aceitar o mapa pronto. O mesmo projeto orienta fixar um release específico em implantações controladas, em vez de seguir automaticamente a versão mais recente, o que evita surpresas de telemetria em uma manhã de segunda-feira.
Roteiro de implantação em produção
Um caminho realista para um parque Windows, com prioridades explícitas:
- P1 — base de processo e arquivo: implantar os eventos 1, 5, 11 e 13 com hash SHA256, excluir binários de antivírus e ferramentas de gestão e enviar o canal Operational ao coletor. A instalação e a troca de configuração não exigem reinicialização: sysmon64 -i arquivo.xml instala e sysmon64 -c arquivo.xml atualiza as regras em produção.
- P2 — telemetria de rede e injeção: depois de uma semana de medição, habilitar o evento 3 apenas em servidores expostos e o evento 10 com exclusões de utilitários de suporte; revisar o volume diário antes de ampliar.
- P2 — governança do perfil: versionar o XML gerado, validar o resultado e medir em máquinas representativas por papel — estação, servidor e controlador de domínio — antes de generalizar, como recomenda a documentação do próprio projeto modular.
Durante a operação, dois sinais merecem alerta próprio: mudanças de estado do serviço e alterações na configuração da ferramenta, que ela mesma registra como eventos. Silêncio total de um host é mais suspeito do que ruído moderado. Quem já explora detecção no kernel Linux encontra a mesma fronteira descrita na análise sobre Falco e Tetragon: a telemetria só vira detecção quando existe regra, revisão periódica e orçamento de ingestão compatível com o volume coletado.