Análise forense de logs no Windows.Como reconstruir um incidente.

Na análise forense de logs no Windows, meu primeiro cuidado não é abrir filtros aleatórios. É preservar o material disponível, registrar onde ele estava, quando foi copiado e qual hash representa aquela evidência.

Uma investigação perde valor quando o arquivo original é sobrescrito, quando o horário não é documentado ou quando ninguém consegue demonstrar de onde aquele log saiu. O objetivo é trabalhar em cópias e manter o EVTX original como referência.

O Event Viewer é a porta de entrada visual, mas os arquivos EVTX também ficam armazenados localmente. Isso permite preservar os registros antes de iniciar filtros, exportações reduzidas ou consultas específicas.

C:WindowsSystem32WinevtLogs

Captura do laboratório O Event Viewer ajuda a localizar rapidamente o canal, o ID e a sequência inicial do evento. Consulta por evento e período O filtro reduz ruído e torna a análise mais rápida quando a janela de tempo já está conhecida.

Os eventos de logon costumam ser o começo da linha do tempo. O 4624 registra uma sessão criada no computador de destino. O 4625 registra uma falha de logon e pode apontar senha incorreta, conta inexistente, bloqueio, serviço mal configurado ou tentativa repetida de acesso.

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = 4624
  StartTime = (Get-Date).AddHours(-1)
} |
Select-Object TimeCreated, Id, ProviderName, Message |
Format-List

Laboratório autorizado A captura mostra a geração controlada de falhas para observar como o Windows registra tentativas repetidas. Filtro por conta Quando uma conta é crítica, o filtro precisa trazer horário, origem e contexto de autenticação. Registro no Security O evento precisa ser lido com campos como conta alvo, status, tipo de logon e origem disponível. Padrão de falha O ponto não é apenas contar eventos: é identificar repetição, alvo, origem e intervalo de tempo.

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = 4625
  StartTime = (Get-Date).AddHours(-24)
} |
Where-Object { $_.Message -match 'Administrator' } |
Select-Object TimeCreated, Id, Message |
Format-Table -Wrap -AutoSize

O evento 4672 registra privilégios especiais atribuídos a um novo logon. Ele pode aparecer em sessões esperadas, inclusive para SYSTEM. Por isso, o foco deve estar em contas inesperadas, horários incomuns e privilégios sensíveis fora do padrão.

Já o 4732 registra que alguém foi adicionado a um grupo local habilitado para segurança. Em ambientes de domínio, mudanças de grupo também podem aparecer em eventos como 4728 e 4756. O que importa é descobrir quem fez a alteração, quem foi incluído, em qual grupo e em qual contexto.

Evento 4672 Privilégios especiais associados a uma nova sessão precisam ser interpretados com contexto. Consulta estruturada Filtrar conta, horário e privilégios reduz falso positivo e melhora a triagem. Ruído controlado Contas de sistema esperadas podem ser separadas para destacar o que realmente precisa de revisão. Evento 4732 Uma mudança de grupo deve registrar responsável, membro adicionado e grupo de destino. Correlação da alteração O script transforma o evento em uma tabela mais fácil de revisar em uma investigação. Resultado para documentação Esse tipo de saída ajuda a registrar evidência técnica de forma objetiva.

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = 4672
  StartTime = (Get-Date).AddHours(-24)
} |
ForEach-Object {
  [xml]$xml = $_.ToXml()
  $data = @{}

  foreach ($item in $xml.Event.EventData.Data) {
    $data[$item.Name] = $item.'#text'
  }

  [PSCustomObject]@{
    DataHora = $_.TimeCreated
    Usuario = $data.SubjectUserName
    Dominio = $data.SubjectDomainName
    Privilegios = $data.PrivilegeList
  }
} |
Where-Object {
  $_.Usuario -notin @('SYSTEM','LOCAL SERVICE','NETWORK SERVICE')
} |
Format-Table -Wrap -AutoSize

Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = 4732
  StartTime = (Get-Date).AddHours(-24)
} |
ForEach-Object {
  [xml]$xml = $_.ToXml()
  $data = @{}

  foreach ($item in $xml.Event.EventData.Data) {
    $data[$item.Name] = $item.'#text'
  }

  [PSCustomObject]@{
    DataHora = $_.TimeCreated
    Responsavel = $data.SubjectUserName
    Grupo = $data.TargetUserName
    MembroSID = $data.MemberSid
    Computador = $_.MachineName
  }
} |
Format-Table -Wrap -AutoSize

Depois de localizar o canal relevante, eu preservo o EVTX original antes de trabalhar com filtros reduzidos. Exportar apenas resultados para XML ou CSV pode ser útil para análise, mas não substitui a preservação do arquivo de evento original.

New-Item -ItemType Directory -Path "C:ColetaEvidencias" -Force

wevtutil epl Security "C:ColetaEvidenciasSecurity.evtx" /ow:true

Get-FileHash -Path "C:ColetaEvidenciasSecurity.evtx" -Algorithm SHA256 |
Format-List |
Out-File "C:ColetaEvidenciasSecurity.evtx.sha256.txt"

Exportação controlada Uma cópia para análise facilita o trabalho sem substituir o material original. Artefato preservado A investigação deve trabalhar sobre uma cópia identificada e rastreável. Registro operacional Guardar o resultado e o caminho do arquivo torna a coleta mais auditável. Hash SHA-256 O hash ajuda a demonstrar que o arquivo não mudou desde a preservação. Validação objetiva O valor de hash deve acompanhar o material preservado e a documentação da coleta.

Uma investigação fica limitada quando a política de auditoria não gera eventos suficientes ou quando o canal Security é pequeno demais para reter o período necessário. Antes de depender dos logs, valide se a auditoria está habilitada e se a retenção faz sentido para o ambiente.

auditpol /get /category:*

auditpol /set /subcategory:"Logon" /success:enable /failure:enable

auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable

Retenção de eventos O tamanho do canal deve ser planejado conforme volume, criticidade e tempo esperado de investigação. Auditoria configurada Antes de confiar em um evento, valide se aquela categoria realmente está sendo auditada. Logon com sucesso e falha Registrar os dois lados ajuda a comparar tentativa, resultado e comportamento esperado. Auditoria por GPO Em ambientes corporativos, a política centralizada reduz diferença entre máquinas e melhora padronização. Mudança de política Quando a auditoria muda, a própria alteração precisa ser investigável. Evento 1102 Uma limpeza de Security log precisa de justificativa, responsável, horário e correlação com outras evidências.

O Sysmon adiciona telemetria detalhada ao Windows, especialmente útil para criação de processos, linha de comando, conexões, alterações de arquivo e outros artefatos que ajudam a entender como uma ação começou.

Ele não substitui o Security log. Ele complementa a investigação, trazendo campos que tornam a correlação mais rica quando existe suspeita de execução, persistência, comportamento anômalo ou movimentação lateral.

Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" `
  -FilterXPath "*[System/EventID=1]" `
  -MaxEvents 20 |
ForEach-Object {
  [xml]$xml = $_.ToXml()
  $data = @{}

  foreach ($item in $xml.Event.EventData.Data) {
    $data[$item.Name] = $item.'#text'
  }

  [PSCustomObject]@{
    DataHora = $_.TimeCreated
    Usuario = $data.User
    Processo = $data.Image
    LinhaComando = $data.CommandLine
    ProcessoPai = $data.ParentImage
    PID = $data.ProcessId
  }
} |
Format-Table -Wrap -AutoSize

Preparação do Sysmon Antes de instalar em produção, avalie política, volume de telemetria e configuração adequada. Configuração XML As regras definem o que será registrado. Mais coleta nem sempre significa melhor investigação. Telemetria enriquecida PowerShell transforma os campos do Sysmon em uma tabela pronta para correlação técnica.

Marque os itens já revisados. O progresso fica salvo apenas neste navegador, para você usar como roteiro em novos laboratórios ou investigações autorizadas.

Nenhum item marcado ainda.