Logs de eventos do Windows e os Event IDs que defensores mais usam

#O que são os logs de eventos do Windows

O Windows mantém um registro contínuo do que acontece na máquina: serviços iniciando, programas travando, pessoas entrando. Cada registro é um evento. Todo evento tem data e hora, um provedor (o componente que o gravou), um Event ID numérico, um nível e um conjunto de campos que depende do tipo de evento. Os eventos ficam agrupados em logs, também chamados de canais, e são gravados como arquivos .evtx em %SystemRoot%\System32\Winevt\Logs.

Três logs importam mais no começo:

• Application guarda eventos gravados por programas e por alguns componentes do Windows. Um aplicativo que trava ou uma atualização que falha costuma aparecer aqui.
• System guarda eventos do próprio Windows e dos drivers: serviços iniciando e parando, o serviço de log de eventos subindo no boot (Event ID 6005), erros de driver.
• Security guarda eventos de auditoria: logons, logoffs, uso de privilégios sensíveis, criação de processos, mudanças em contas e políticas. A maior parte deste artigo trata dele, e ele é o único dos três que um usuário comum não consegue abrir.

Dá para ver essa diferença de acesso no PowerShell. Na máquina usada neste artigo (Windows 11, Windows PowerShell 5.1), este comando rodou em um shell sem direitos de administrador:

Get-WinEvent -ListLog System,Application | Format-Table LogName,RecordCount,IsEnabled -Auto

LogName     RecordCount IsEnabled
-------     ----------- ---------
System            36196      True
Application       19965      True

Ao acrescentar Security ao mesmo comando, saiu um erro para esse log: o Windows não conseguiu obter as informações dele porque a operação não era autorizada. As suas contagens de registros serão outras.

#Por que isso importa

Muitas detecções no Windows são construídas sobre o log Security. Uma regra de SIEM para tentativa de adivinhar senha conta eventos 4625. Uma regra para sessão administrativa suspeita olha 4624 e 4672 juntos. Uma regra para adulteração de logs procura 1102. O artigo sobre SIEM do Manual de Campo explicou como essas regras funcionam. Ler os eventos à mão em uma máquina permite conferir se as premissas de uma regra valem nos seus sistemas.

O log Security só contém o que a política de auditoria manda o Windows registrar. Se a política não audita logons com falha, o Windows não grava nenhum 4625, e uma regra que conta esses eventos nunca dispara. Do lado do SIEM, isso parece exatamente uma máquina tranquila. Por isso, conferir a política de auditoria vem antes de ler o log.

#Como a auditoria funciona

#A política de auditoria decide o que existe

O Windows agrupa as configurações de auditoria em categorias, e cada categoria em subcategorias. Cada subcategoria pode registrar sucessos, falhas, os dois ou nada. As categorias são Account Logon, Account Management, Detailed Tracking, DS Access, Logon/Logoff, Object Access, Policy Change, Privilege Use e System.

A categoria Logon/Logoff reúne as subcategorias por trás da maioria dos eventos deste artigo: Logon (4624 e 4625), Logoff (4634), Account Lockout (que a Microsoft também lista para o 4625) e Special Logon (4672). A criação de processos, evento 4688, pertence à subcategoria Process Creation, dentro de Detailed Tracking.

O auditpol é a ferramenta nativa para ler a política. auditpol /list mostra os nomes de categorias e subcategorias e funciona em um shell comum. auditpol /get lê as configurações de fato. A referência da Microsoft diz que ele exige permissão de leitura na política ou o direito "Manage auditing and security log" (SeSecurityPrivilege), e um shell comum, sem elevação, não tem nenhum dos dois.

auditpol /list /category /v

Na máquina usada neste artigo, com o Windows em português, esse comando rodou sem elevação e mostrou cada categoria com o nome traduzido e um GUID. Logon/Logoff tinha o GUID {69979849-797A-11D9-BED3-505054503030}. O nome em inglês ainda funcionou lá com auditpol /list /subcategory:"Logon/Logoff", que listou doze subcategorias. Se o seu sistema recusar um nome, passe o GUID.

#Os Event IDs que você mais vai usar

#4624 e 4625: logons

Os dois eventos são gravados no computador onde o logon aconteceu. Se alguém digita a senha errada no seu notebook, o 4625 vai para o log Security do seu notebook. Os dois compartilham a maior parte dos campos:

• Subject é a conta que informou o logon, muitas vezes o próprio computador ou SYSTEM.
• Logon Type diz como o logon aconteceu. Os valores comuns são 2 (Interactive, no teclado), 3 (Network, como um compartilhamento de arquivos), 4 (Batch), 5 (Service), 7 (Unlock), 10 (RemoteInteractive, Área de Trabalho Remota) e 11 (CachedInteractive, credenciais de domínio guardadas na máquina).
• New Logon (no 4624) ou Account For Which Logon Failed (no 4625) é a conta que está entrando, com Security ID, nome e domínio. No 4624, essa seção também traz o Logon ID da nova sessão.
• Failure Information (só no 4625) traz um código Status e um Sub Status. A página da Microsoft lista os códigos que vale acompanhar: 0xC000006A para senha errada, 0xC0000064 para nome de usuário que não existe, 0xC000006D para nome de usuário ou informação de autenticação inválidos, 0xC0000072 para conta desativada. A mesma página indica 0xC0000234, "Account locked out", como o status típico quando a falha vem de uma conta bloqueada. Vários 0xC0000064 seguidos podem indicar alguém enumerando nomes de usuário.
• Process Information mostra o processo que tentou o logon, e Network Information traz o nome da estação, o endereço de origem e a porta de origem. 127.0.0.1 ou ::1 significa localhost, e a porta é 0 em logons interativos.

No Windows 10 e posteriores, o 4624 também traz Elevated Token, que diz se a sessão tem privilégios de administrador.

#4634: logoff, e por que o Logon ID importa

O 4634 diz que uma sessão de logon terminou. Sozinho, ele diz pouco. O valor dele vem do Logon ID: o mesmo valor hexadecimal aparece no 4624 que abriu a sessão, em qualquer 4672 dessa sessão, nos 4688 dos processos que ela iniciou e no 4634 que a fechou. Seguir um Logon ID pelo log reconstrói uma sessão do começo ao fim. A Microsoft observa que os Logon IDs só são únicos entre reinicializações do mesmo computador, então sempre junte o ID a um intervalo de tempo.

#4672: privilégios especiais

O Windows grava o 4672 quando um novo logon recebe algum privilégio de uma lista de privilégios sensíveis, como SeDebugPrivilege (depurar programas), SeBackupPrivilege (fazer backup de arquivos e pastas) ou SeTcbPrivilege (agir como parte do sistema operacional).

Todo logon de SYSTEM gera um 4672, então o log tem muitos deles. A Microsoft recomenda olhar os casos em que a conta não é LOCAL SYSTEM, NETWORK SERVICE ou LOCAL SERVICE, nem um administrador que você espera que tenha esses privilégios.

#4688: criação de processo

O 4688 é gravado toda vez que um processo novo inicia, desde que a subcategoria Process Creation esteja auditada. Ele registra o nome do novo processo, o nome do processo criador (o pai), a conta, o Token Elevation Type (se o processo rodou com token completo, elevado ou limitado) e o nível de integridade.

Ele também tem o campo Process Command Line, que vem vazio por padrão. A página da Microsoft diz que ele só é preenchido quando a configuração de Política de Grupo "Administrative Templates\System\Audit Process Creation\Include command line in process creation events" está ativada. Sem ela, você sabe que o powershell.exe iniciou, mas não o que mandaram ele fazer.

#1102: o log foi limpo

O 1102 significa que alguém limpou o log Security. Ele é gravado pelo provedor Microsoft-Windows-Eventlog e registra a conta que fez isso. A orientação da Microsoft é curta: normalmente você não deveria ver esse evento, raramente há motivo para limpar o log Security à mão, e cada ocorrência merece investigação.

#O que o Sysmon acrescenta

O Sysmon (System Monitor) é uma ferramenta Sysinternals publicada pela Microsoft. Ele se instala como serviço e driver, continua ativo entre reinicializações e grava os próprios eventos em Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. É um download à parte, que não vem na instalação padrão do Windows, e a Microsoft lista como suportados o Windows 11 e o Windows Server 2019 ou posterior.

Em comparação com o log Security nativo, o Sysmon dá mais detalhe sobre atividades que você só veria em parte:

• O Event ID 1, criação de processo, inclui a linha de comando completa, hashes do arquivo (SHA1 por padrão, com MD5, SHA256 e IMPHASH disponíveis) e um ProcessGuid que continua único mesmo quando o Windows reutiliza IDs de processo.
• O Event ID 3 registra conexões de rede com o processo por trás de cada uma. Ele vem desativado por padrão.
• Outros IDs cobrem criação de arquivos (11), consultas DNS (22), mudanças no registro, named pipes, assinaturas WMI e um processo abrindo outro, como o lsass.exe (10).

Um arquivo de configuração XML decide quais eventos o Sysmon inclui ou exclui. A Microsoft afirma que o Sysmon não analisa os eventos que gera e não tenta se esconder de atacantes. A leitura fica com um SIEM ou com um analista.

Instalar o Sysmon muda o sistema, por isso o laboratório deste artigo não faz isso.

#Prática: encontre o seu próprio logon com falha

Você vai criar um logon com falha no seu computador, com a sua conta, e encontrá-lo de três jeitos. Não mude a política de auditoria durante este laboratório. Se a política não registrar logons com falha, esse resultado já é o aprendizado: anote e pare aí.

#Passo 1: abra um PowerShell elevado

Clique com o botão direito no Windows PowerShell ou no Terminal e escolha Executar como administrador. Confira se o shell está mesmo elevado:

([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)

True significa que você consegue ler o log Security. Na máquina usada neste artigo, o shell disponível devolveu False. Os comandos abaixo rodaram lá mesmo assim, e as falhas aparecem como foram observadas, porque vale a pena conhecê-las. Onde entraria a saída elevada, este artigo descreve os campos a procurar, com base na documentação da Microsoft.

#Passo 2: confira a política de auditoria

auditpol /get /category:"Logon/Logoff"

Em um shell elevado, isso mostra cada subcategoria com a sua configuração. Ache a linha Logon. Para este laboratório, ela precisa incluir falha, ou seja, sucesso e falha, ou só falha. Se ela disser que não há auditoria, o Windows não vai gravar o 4625 e o resto do laboratório não vai encontrar nada.

Sem elevação, na máquina usada neste artigo, o comando mostrou o erro 0x00000522 com uma mensagem dizendo que o cliente não tem o privilégio necessário, e saiu com o código 1314.

#Passo 3: gere o evento

Pressione Win+L para bloquear a tela. Digite a senha errada uma vez e depois entre com a certa. Anote o horário.

Use a senha, não o PIN. Se você costuma usar o Windows Hello, escolha a opção de senha na tela de entrada. Este artigo não testou o que um PIN errado gera.

#Passo 4: encontre a falha com Get-WinEvent

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

O -FilterHashtable aplica o filtro enquanto os eventos são lidos, o que a documentação da Microsoft descreve como mais eficiente do que mandar tudo para o Where-Object. O -MaxEvents 5 fica com as cinco correspondências mais recentes, porque o Get-WinEvent devolve primeiro as mais novas.

Em um shell elevado, o primeiro resultado deve ter o horário que você anotou. Na Message, confira:

• Logon Type. O exemplo de 4625 da Microsoft é um logon interativo, tipo 2, com o processo chamador C:\Windows\System32\winlogon.exe.
• Account For Which Logon Failed, que deve ser a sua conta.
• Status e Sub Status. Para senha errada, procure 0xC000006A em um dos dois.
• Source Network Address e Source Port. Para um logon no seu próprio teclado, espere um valor local como 127.0.0.1 e porta 0, como no exemplo da Microsoft.

Sem elevação, esse mesmo comando engana você. Na máquina usada neste artigo, ele não relatou problema de permissão. Ele mostrou o erro de que nenhum evento correspondente aos critérios de seleção foi encontrado. Um Get-WinEvent -LogName Security -MaxEvents 1 simples, no mesmo shell, mostrou a causa real: uma operação não autorizada. Se você vir "nenhum evento encontrado" em um shell sem elevação, confira a elevação antes de concluir que o log está vazio.

#Passo 5: encontre o logon bem-sucedido

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 5 | Select-Object TimeCreated, Id

Você deve ver um 4624 alguns segundos depois do seu 4625, com outros 4624 em volta, porque serviços e o próprio sistema fazem logon o tempo todo. Abra a mensagem completa do evento mais próximo do seu horário e confira o Logon Type e o nome da conta. Acrescentar StartTime=(Get-Date).AddMinutes(-15) à hashtable limita a busca aos últimos quinze minutos.

Uma senha errada seguida da certa, na mesma conta, no teclado, com segundos de diferença, é erro de digitação. A mesma falha repetida contra muitas contas a partir de um único endereço de rede aponta para tentativa de adivinhar senhas, e as regras de detecção são escritas para separar esses dois casos.

#Passo 6: a mesma busca com wevtutil

wevtutil qe Security /c:5 /rd:true /f:text /q:"*[System[(EventID=4625)]]"

O wevtutil é a ferramenta de linha de comando mais antiga para logs de eventos. qe consulta eventos, /c:5 limita a quantidade, /rd:true lê do mais novo para o mais antigo, /f:text imprime texto em vez de XML e /q recebe um filtro XPath. Elevado, você recebe os mesmos eventos do passo 4. Tire o /f:text para ver o XML bruto, com os nomes de campo que as regras de detecção usam, como TargetUserName, Status e LogonType. Em um Windows em outro idioma, o texto da mensagem aparece traduzido, mas os nomes dos campos no XML continuam em inglês.

Sem elevação, na máquina usada neste artigo, ele informou que não conseguiu abrir a consulta de evento porque o acesso foi negado, e saiu com o código 5.

#Passo 7: veja no Visualizador de Eventos

Rode eventvwr.msc. Se for solicitado, permita que ele rode como administrador. Vá em Logs do Windows > Segurança, escolha Filtrar Log Atual e digite 4625 no campo de Event IDs. Abra o evento. A aba Geral mostra a mesma mensagem que você leu no PowerShell. A aba Detalhes, no modo XML, mostra os nomes brutos dos campos. Deixe esse evento aberto: o artigo sobre Sigma compara uma regra com ele.

#Erros comuns

• Confiar em "nenhum evento encontrado" vindo de um shell comum. Como o passo 4 mostrou, uma consulta Get-WinEvent -FilterHashtable sem elevação no log Security pode relatar que não achou nada em vez de acesso negado.
• Supor que um evento existe sem conferir a política. Sem configuração de auditoria, não há evento. O mesmo vale para campos: a linha de comando do 4688 fica vazia até outra política ativá-la.
• Ler um evento isolado. Um único 4625 diz pouco. Olhe o 4624 que vem depois, o Logon ID e o intervalo de tempo.
• Limpar o log depois do laboratório para deixar tudo arrumado. Você destrói a evidência que acabou de criar e gera um 1102 que alguém talvez precise investigar.
• Esquecer que os logs giram. Na máquina usada neste artigo, Get-WinEvent -ListLog Application mostrou tamanho máximo de 20971520 bytes no modo Circular: quando o log enche, os eventos antigos são sobrescritos. Confira o log Security do mesmo jeito, com elevação, antes de contar com os eventos do mês passado.

#Como ir além

• Leia a página da Microsoft de cada evento deste artigo. Todas terminam com recomendações de monitoramento de segurança que já são quase ideias de detecção prontas.
• Monte uma máquina virtual em um laboratório caseiro legal, instale o Sysmon lá com um arquivo de configuração, rode alguns comandos e compare o evento 1 do Sysmon com o 4688 do mesmo processo.
• Transforme o evento que você encontrou em uma detecção: o próximo artigo, como escrever sua primeira regra Sigma, monta e testa uma regra exatamente para esse 4625.

#Fontes

• Microsoft Learn, 4625(F) An account failed to log on
• Microsoft Learn, 4624(S) An account was successfully logged on
• Microsoft Learn, 4634(S) An account was logged off
• Microsoft Learn, 4672(S) Special privileges assigned to new logon
• Microsoft Learn, 4688(S) A new process has been created
• Microsoft Learn, 1102(S) The audit log was cleared
• Microsoft Learn, Get-WinEvent
• Microsoft Learn, Sysmon
• Microsoft Learn, auditpol get
• Microsoft Learn, wevtutil