Cibersegurança e segurança da informação

Sysmon Event ID 3 e 22: Conexões de Rede e Consultas DNS

7 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre Sysmon Event ID 3 e 22 na área de Windows e Identidade

Resposta rápida

O Sysmon Event ID 3 e 22 requer a leitura do evento completo e não apenas do Event ID: tempo, computador, utilizador, Logon ID, Processo, fonte de rede e contexto organizacional. A conclusão é gerada pela correlação entre várias fontes.

A investigação de Windows e Identidade baseia-se na combinação de eventos de autenticação, criação de processos, alterações de permissões, telemetria do Sysmon e contexto organizacional. Um único evento quase nunca fornece uma conclusão completa. Este artigo foca-se no Sysmon Event ID 3 e 22 e destina-se a analistas de SOC e investigadores de Endpoint. O objetivo é fornecer uma metodologia de trabalho que possa ser aplicada na prática, em entrevistas profissionais e em ambientes de trabalho, sem se limitar a uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. ProcessGuid, DestinationIp, DestinationPort podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construímos a verificação em torno de uma questão de investigação, evidências necessárias e um critério claro para a conclusão.

O cenário prático neste artigo é: Conectar Query a um processo e IP numa Timeline. Todos os exemplos são dados de laboratório ou descrições de processos. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização explícita, um Scope definido e a capacidade de parar o teste.

Campos do Evento 3

Os campos importantes não são necessariamente aqueles apresentados no topo do ecrã. No Sysmon Event ID 3 e 22, é necessário identificar identificadores estáveis, tempo, origem, destino, resultado e contexto. Exemplos úteis são ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime. O objetivo é permitir a correlação entre registos e não apenas a leitura de um único evento.

Recomenda-se criar um pequeno dicionário de dados: nome do campo, significado, formato, origem, valores nulos esperados e se é fiável para ligação. Desta forma, é possível distinguir entre um campo de exibição e um identificador investigativo, e identificar quando um conector ou versão alterou o esquema.

Campos do Evento 22

Ligação por ProcessGuid

A implementação correta começa com os requisitos e não com o padrão. São definidos quais os Use Cases suportados, o volume de dados, quem gere a configuração e qual o mecanismo de Rollback. No Sysmon Event ID 3 e 22, é necessário separar as definições que geram telemetria das definições que a filtram ou enriquecem.

Após a definição, é executado um teste controlado com dados esperados, verificando se o evento foi registado, se os campos principais existem e se a alteração não criou carga ou um ponto cego. Cada alteração é guardada numa versão, com data, proprietário, motivo e resultado do teste.

Identificação de Domínios e Destinos Anormais

A investigação do Sysmon Event ID 3 e 22 começa com a formulação de uma hipótese: que comportamento explica a descoberta, e que evidências a confirmarão ou refutarão. Em seguida, estende-se a janela de tempo, verificam-se as entidades e procura-se uma sequência antes e depois do evento.

Uma boa correlação combina pelo menos dois tipos de informação de ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime. Para cada descoberta, indica-se o que prova, o que não prova e qual é o próximo passo. Se os dados não forem suficientes, indica-se 'Unknown' e não se transforma a ausência de evidência em evidência de ausência.

Limitações e Validação em Fontes Adicionais

Nesta fase, são definidas as evidências necessárias para responder à questão da investigação. Para o Sysmon Event ID 3 e 22, os pontos de base são o Event ID e o Provider, Computer, User e Logon ID, Process, Parent e Command Line, Source IP, Workstation e Logon Type. Para cada fonte, são documentados o proprietário, o período de retenção, o fuso horário, o atraso na receção e os campos que podem estar em falta.

A qualidade da recolha não é medida pelo facto de o registo 'chegar'. É necessário verificar a Completeness, Latency, Parsing, Duplicate events e a sincronização de tempo. Um teste Canary ou um evento de laboratório conhecido permite verificar se a operação apareceu na origem, passou pelo Pipeline e pode ser pesquisada nos campos corretos.

Pontos de Verificação Exclusivos

Neste tópico, é recomendável construir um mapa de evidências focado antecipadamente. Os principais pontos de verificação são: ProcessGuid, DestinationIp, DestinationPort, QueryName, QueryResults, UtcTime, query name, response code, TTL, subdomain entropy. A lista não é uma lista de verificação automática; cada item é escolhido porque pode ligar uma entidade, ação e tempo ou explicar um comportamento legítimo.

ProcessGuid: Defina qual é o valor esperado, o que será considerado excecional e qual a fonte adicional que verificará a descoberta.
DestinationIp: Defina qual é o valor esperado, o que será considerado excecional e qual a fonte adicional que verificará a descoberta.
DestinationPort: Defina qual é o valor esperado, o que será considerado excecional e qual a fonte adicional que verificará a descoberta.
QueryName: Defina qual é o valor esperado, o que será considerado excecional e qual a fonte adicional que verificará a descoberta.
QueryResults: Defina qual é o valor esperado, o que será considerado excecional e qual a fonte adicional que verificará a descoberta.
UtcTime: Defina qual é o valor esperado, o que será considerado excecional e qual a fonte adicional que verificará a descoberta.

Quando um dos pontos focais não está disponível, a lacuna deve ser documentada e uma alternativa deve ser escolhida. Por exemplo, se o identificador de Processo não for estável, pode-se usar tempo, Host, User e Parent; se a carga útil for encriptada, usa-se Metadados, volume, frequência e contexto TLS/DNS.

Processo de Trabalho Recomendado

Defina o Scope e uma única questão de trabalho sobre Sysmon Event ID 3 e 22.
Registe as fontes de dados e as evidências necessárias: ProcessGuid, DestinationIp, DestinationPort, QueryName.
Crie uma Baseline curta de comportamento normal ou resultado esperado.
Execute o teste mínimo num ambiente de laboratório e guarde tempo, entrada e saída.
Construa uma Timeline ou tabela de comparação e separe facto de interpretação.
Faça um Pivot para uma fonte adicional para confirmar ou refutar a explicação inicial.
Resuma a decisão, limitações, ação recomendada e critério de Retest.

Cenário Prático

O cenário escolhido é a ligação de uma Query a um processo e IP numa Timeline. O objetivo do exercício não é provar a capacidade de ataque, mas sim praticar a recolha, comparação e documentação de forma segura. Antes de iniciar o trabalho, são definidos dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser apresentado um produto que um analista ou outro testador possa rever: uma captura de ecrã ou exportação da evidência, uma Timeline curta, uma hipótese inicial, uma evidência de confirmação, uma limitação e uma recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Etapa	O que é realizado	Produto
Preparação	Defina Scope, tempo e destino. Registe quais os campos ou evidências de ProcessGuid, DestinationIp, DestinationPort que se espera que apareçam.	Plano de teste curto
Geração de dados	Execute uma ação segura e simulada relacionada com Sysmon Event ID 3 e 22, sem informações reais ou impacto num sistema de produção.	Evento/Pedido/Fluxo controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o fuso horário, os identificadores e a integridade.	Duas evidências ligadas
Análise	Escreva o que cada evidência prova, o que não prova e qual a explicação legítima possível.	Conclusão intermédia
Conclusão	Escolha fechar, escalar, encontrar ou afinar; adicione uma recomendação e Retest.	Produto documentado

Lista de Verificação Prática

Verifique e documente: Event ID e o Provider.
Verifique e documente: Computer, User e Logon ID.
Verifique e documente: Process, Parent e Command Line.
Verifique e documente: Source IP, Workstation e Logon Type.
Verifique e documente: Group/Privilege changes.
Verifique e documente: Sysmon ProcessGuid ou SessionGuid.
Indique o fuso horário, a versão da ferramenta e a hora da recolha.
Guarde os dados brutos antes de filtrar ou alterar.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina o proprietário e a ação de acompanhamento com uma data.

Erros Comuns

Confiar apenas no Event ID sem campos.
Confundir o Logon com a origem do ataque.
Ignorar o Logon Type.
Ligar Processos apenas por PID.
Assumir que todo PowerShell é malicioso.
Fechar um evento sem verificar o Domain Controller.

Resumo e CTA

Sysmon Event ID 3 e 22: Conexões de Rede e Consultas DNS é um tópico que liga o conhecimento técnico à disciplina de trabalho. Comece com uma pergunta, recolha apenas evidências relevantes, mantenha o contexto e o tempo, e escolha uma ação que possa ser justificada e retestada.

No curso Cybersecurity & AI da HPI, estes princípios são praticados usando sistemas, registos e laboratórios. O próximo passo natural é passar para os artigos relacionados, realizar o exercício de laboratório e guardar o produto como parte de um portfólio profissional.

Perguntas frequentes

O Sysmon Event ID 3 e 22 por si só prova um ataque ou uma vulnerabilidade?

Não. Fornece um sinal ou uma descoberta que precisa de contexto, verificação e uma fonte adicional. Uma conclusão profissional baseia-se numa sequência de evidências e na conformidade com o comportamento esperado.

O que fazer quando faltam alguns dados?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não complete campos com suposições ou apresente 'Unknown' como aceitável.

Por quanto tempo as evidências devem ser mantidas?

O tempo depende da política, regulamentação, custo e tipo de evento. É importante definir antecipadamente a Retenção, Legal hold e a capacidade de exportar evidências num formato verificável.

Como praticar sem comprometer um sistema real?

Use máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, as condições de paragem e faça um backup antes de iniciar o trabalho.