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

Sysmon Event ID 1: Criação de uma Árvore de Processos para Investigação

6 min de leituraPublicado: 5 de agosto de 2026

Representação visual profissional sobre Sysmon Event ID 1 na área de Windows e Identity

Resposta rápida

O Sysmon Event ID 1 exige a leitura do evento completo e não apenas do Event ID: tempo, computador, utilizador, Logon ID, processo, origem da rede e contexto organizacional. A conclusão é formada pela correlação de várias fontes.

A investigação de Windows e Identity baseia-se numa combinação de eventos de autenticação, criação de processos, alterações de permissões, telemetria Sysmon e contexto organizacional. Um único evento quase nunca fornece uma conclusão completa. Este artigo foca-se no Sysmon Event ID 1 e destina-se a analistas SOC. O objetivo é fornecer um método de trabalho que pode ser aplicado na prática, numa entrevista profissional e num ambiente de trabalho, sem se contentar com uma definição de dicionário.

O principal desafio é que os dados estão quase sempre incompletos. ProcessGuid, ParentProcessGuid, Image podem indicar uma direção, mas o seu significado depende do tempo, do ativo, do utilizador e da atividade esperada. Por isso, construiremos 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 no artigo é: a reconstituição de uma cadeia Office-to-PowerShell simulada. Todos os exemplos são dados de laboratório ou descrições processuais. Quando se trata de Penetration Testing, Web ou Cloud, deve-se trabalhar apenas com autorização expressa, escopo definido e capacidade de parar o teste.

Campos do Event ID 1

Os campos importantes não são necessariamente os que são apresentados no topo do ecrã. No Sysmon Event ID 1, devem ser identificados identificadores estáveis, tempo, origem, destino, resultado e contexto. Exemplos úteis são ProcessGuid, ParentProcessGuid, Image, CommandLine, Hashes, User. 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 visualização e um identificador investigativo, e identificar quando um Connector ou uma versão alterou o Schema.

ProcessGuid vs ProcessId

Para entender a diferença no contexto do Sysmon Event ID 1, é importante comparar objetivos e não apenas ferramentas. Uma opção oferece amplitude ou velocidade, e outra oferece verificação profunda ou contexto. A escolha correta depende da pergunta: é necessária descoberta, investigação, prova de impacto, contenção ou relatório.

Uma tabela de comparação profissional deve incluir pelo menos: tipo de entrada, nível de certeza, custo operacional, impacto potencial, limitações e acompanhamento necessário. Em caso de dúvida, usa-se a abordagem menos intrusiva e adiciona-se uma fonte complementar em vez de tirar uma conclusão muito ampla.

Relações Parent-Child

O tópico 'Parent-Child relationships' é uma parte central do trabalho com o Sysmon Event ID 1. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático da ferramenta sem entender o objetivo.

Na prática, registe ProcessGuid, ParentProcessGuid, Image, CommandLine, Hashes, compare com o comportamento esperado e defina pelo menos um Pivot. O resultado deve ser verificável por outro analista, incluindo limitações e próximos passos.

CommandLine e IntegrityLevel

O tópico 'CommandLine e IntegrityLevel' é uma parte central do trabalho com o Sysmon Event ID 1. Recomenda-se dividi-lo em três perguntas: qual é a entrada, que decisão se quer tomar e que evidência é suficiente para justificá-la. Estas perguntas impedem o uso automático da ferramenta sem entender o objetivo.

Criação de Árvore e Linha do Tempo

A Linha do Tempo é a espinha dorsal do Sysmon Event ID 1. Normalizam-se os tempos para UTC ou indica-se explicitamente o fuso horário, guardam-se o Event time e o Ingestion time, e conectam-se eventos através de identificadores estáveis. A linha deve incluir tempo, origem, entidade, ação, resultado e fiabilidade.

Uma lacuna ou contradição não é uma falha no documento, mas sim uma descoberta. Clock drift, atraso na ingestão, NAT, reutilização de PID ou uma sessão contínua podem alterar a ordem. Por isso, indicam-se intervalos de incerteza e mantém-se um link de volta à evidência bruta.

Pontos de Verificação Exclusivos

Neste tópico, recomenda-se construir antecipadamente um mapa de evidências focado. Os principais pontos de verificação são: ProcessGuid, ParentProcessGuid, Image, CommandLine, Hashes, User. A lista não é um Checklist automático; cada item é selecionado 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 anómalo e qual fonte adicional verificará a descoberta.
ParentProcessGuid: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
Image: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
CommandLine: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
Hashes: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.
User: Defina qual é o valor esperado, o que será considerado anómalo e qual fonte adicional verificará a descoberta.

Quando um dos pontos não está disponível, a lacuna deve ser documentada e uma alternativa escolhida. Por exemplo, se o Process identifier não for estável, pode-se usar tempo, Host, User e Parent; se o Payload for encriptado, usam-se Metadados, volume, frequência e contexto TLS/DNS.

Processo de Trabalho Recomendado

Defina o Scope e uma pergunta de trabalho sobre o Sysmon Event ID 1.
Registe as fontes de dados e as evidências necessárias: ProcessGuid, ParentProcessGuid, Image, CommandLine.
Crie uma pequena Baseline 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 Linha do Tempo ou tabela de comparação e separe facto de interpretação.
Faça um Pivot para uma fonte adicional para verificar 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 reconstituição de uma cadeia Office-to-PowerShell simulada. 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 começar, definem-se dados simulados, uma janela de tempo e um resultado esperado.

No final do exercício, deve ser entregue um produto que outro analista ou verificador possa criticar: uma imagem ou Export da evidência, uma Linha do Tempo curta, uma hipótese inicial, evidência de confirmação, limitação e recomendação. Quando não há evidência suficiente, a conclusão correta é que o cenário não foi provado.

Etapa	O que é executado	Produto
Preparação	Defina Scope, tempo e objetivo. Registe quais campos ou evidências de ProcessGuid, ParentProcessGuid, Image são esperados para aparecer.	Plano de teste curto
Criação de dados	Execute uma ação segura e simulada relacionada ao Sysmon Event ID 1, sem informações reais ou impacto no sistema de produção.	Evento/Pedido/Fluxo controlado
Recolha	Recolha a evidência bruta e o contexto de uma fonte adicional. Verifique o Time zone, identificadores e 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 provisória
Conclusão	Escolha um encerramento, escalonamento, Finding ou Tuning; adicione uma recomendação e Retest.	Produto documentado

Checklist Prático

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 Time zone, versão da ferramenta e hora de recolha.
Guarde os dados brutos antes da filtragem ou alteração.
Escreva o que a descoberta prova e o que ainda é desconhecido.
Defina um proprietário e uma ação de acompanhamento com um prazo.

Erros Comuns

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

Resumo e CTA

Sysmon Event ID 1: Criação de uma Árvore de Processos para Investigação é um tópico que conecta conhecimento técnico com 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 verificada novamente.

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

Perguntas frequentes

O Sysmon Event ID 1 por si só prova um ataque ou uma vulnerabilidade?

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

O que fazer quando alguns dados estão em falta?

Documente o que falta, verifique uma fonte alternativa e reduza o nível de confiança. Não deve preencher campos por suposição ou apresentar 'Desconhecido' como válido.

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?

Utilize máquinas virtuais, dados simulados, CTF ou um laboratório dedicado. Em testes autorizados, defina o Scope, as Stop conditions e o backup antes de iniciar o trabalho.