Sysmon no SOC é a camada que dá visibilidade interna às máquinas Windows: um serviço e driver da Microsoft que registra criação de processos com linha de comando completa, conexões de rede e mudanças no timestamp de criação de arquivos no log de eventos do Windows. Para uma equipe enxuta, é a forma mais direta de transformar cada endpoint em fonte de telemetria estruturada, sem custo de licença, alimentando detecções que o monitoramento de rede sozinho não sustenta. O caminho curto tem três passos: instalar o agente com um arquivo de configuração, ligar o canal de eventos ao SIEM e escrever correlação sobre os identificadores que o Sysmon padroniza — começando pela leitura de credenciais que antecede o movimento lateral com hash roubado.
O que o Sysmon registra
A documentação oficial resume o escopo: além da criação de processos com a linha de comando do processo atual e do processo pai, o Sysmon registra o hash dos arquivos de imagem com SHA1 no padrão, MD5, SHA256 ou IMPHASH, e aceita vários algoritmos ao mesmo tempo. Cada evento carrega um ProcessGuid, que mantém a correlação entre eventos mesmo quando o Windows reutiliza identificadores de processo, e um GUID de sessão que agrupa a atividade da mesma sessão de logon. O serviço também registra carregamento de drivers e DLLs com assinatura e hash, leitura bruta de disco e volumes, criação e sobrescrita de arquivos e mudanças em chaves e valores de registro.
Dois limites importam antes de qualquer expectativa: o Sysmon não analisa os eventos que gera — a detecção é trabalho do SIEM — e o serviço não tenta se esconder do invasor. Na versão atual, publicada em 10 de setembro de 2026 como Sysmon v15.22, o suporte declarado cobre cliente Windows 11 ou superior e servidor Windows Server 2019 ou superior, com instalação e desinstalação sem reinício. O serviço roda como processo protegido, o que reduz a superfície de interação em modo usuário, e gera eventos desde o início do boot.
Eventos que sustentam a detecção
Os eventos numerados do Sysmon são o vocabulário das regras do SOC. A tabela reúne os cinco que mais rendem detecção de intrusão em ambientes Windows.
| ID | O que captura | Uso no SOC |
|---|---|---|
| 1 | Criação de processo com linha de comando, hash e GUID | Árvore pai-filho e execução suspeita |
| 3 | Conexão TCP/UDP ligada ao processo de origem | Atribuir tráfego de saída ao binário |
| 8 | CreateRemoteThread em outro processo | Injeção de código |
| 10 | Abertura de outro processo com acesso | Leitura do LSASS e credential dumping |
| 11 | Criação ou sobrescrita de arquivo | Pastas de inicialização e diretórios temporários |
O evento 10 é o que dá base para detectar ferramentas que leem a memória do processo Local Security Authority para roubar credenciais usadas em ataques de pass-the-hash — o padrão clássico contra o Lsass.exe antes do salto para outras máquinas. A própria documentação avisa que habilitá-lo sem filtro gera volume alto de registro quando utilitários de diagnóstico abrem processos repetidamente. Já o evento 3 vem desativado por padrão: ativá-lo exige exclusões por processo, senão o log incha com tráfego de navegador e atualizadores.
Da matriz ATT&CK ao log
A técnica de credential dumping catalogada pelo MITRE ATT&CK como OS Credential Dumping (T1003) descreve o outro lado dessa telemetria: adversários extraem credenciais em forma de hash ou senha em texto claro para depois executar movimento lateral e acessar informações restritas. Ligar o evento 10 a essa técnica transforma log bruto em cobertura mensurável: o evento aponta o processo de origem, o alvo e o tipo de acesso, e a regra de correlação declara qual sub-técnica ela cobre. O mesmo raciocínio vale para o evento 8 contra injeção de código e para o evento 11 contra persistência em pastas de inicialização. Mapear cada regra a uma técnica é o que impede a sensação de cobertura que a contagem de alertas sozinha cria.
Configuração com filtros XML
O comportamento do Sysmon é controlado por um arquivo XML de filtragem, com blocos de inclusão e exclusão por tipo de evento e condições como is, contains, begin with e end with; regras sobre o mesmo campo se comportam como OR, regras sobre campos diferentes como AND, e grupos de regras permitem fixar a combinação explicitamente. Um procedimento enxuto:
- Instale em uma máquina de laboratório com sysmon64 -accepteula -i config.xml e confirme o canal em Applications and Services Logs/Microsoft/Windows/Sysmon/Operational.
- Parta de um template comentado, como o sysmon-config, e leia as seções antes de editar.
- Observe o resultado por alguns dias: uma configuração precisa ser observada e ajustada no próprio ambiente antes de uma implantação ampla, inclusive para excluir os eventos do antivírus, que enchem o log de informação inútil.
- Aplique a revisão com sysmon64 -c config.xml, valide o schema com sysmon64 -s e monitore o evento 16, que registra mudanças de configuração.
Como levar os eventos ao SOC
Coletar é metade do trabalho. A documentação recomenda encaminhar os eventos por Windows Event Collection ou agentes de SIEM e, a partir daí, analisá-los para identificar atividade maliciosa ou anômala. Em laboratório próprio, um exemplo hipotético com logs sintéticos: executar no endpoint de teste uma linha de comando gerada por script e conferir no SIEM se o evento 1 chega com linha de comando, hash e ProcessGuid corretos — esse teste valida coleta, parsing e correlação antes de qualquer regra entrar em produção. Telemetria de endpoint é o que sustenta a resposta descrita no guia de detecção e resposta a ransomware: sem o evento de criação de processo ligado ao arquivo que ele executa, a triagem perde a cadeia de execução do invasor.
