Ler ficheiros .evtx sem uma máquina Windows

O registo nunca está na máquina onde está sentado

O padrão é sempre o mesmo. Aconteceu alguma coisa — uma suspeita de compromisso, uma tempestade de bloqueios de contas, um serviço que morreu às 03:00 — e a prova é um registo de eventos do Windows que alguém exportou, copiou para uma imagem ou extraiu de uma máquina que não pode arrancar, onde não pode iniciar sessão ou que não tem licença para tocar. A sua própria máquina é um Mac, uma estação de trabalho Linux ou um portátil empresarial bloqueado, sem nenhuma máquina virtual Windows à vista. O Visualizador de Eventos não virá ajudar.

A boa notícia é que um ficheiro .evtx é um formato binário documentado e autónomo. Tudo o que o Visualizador de Eventos lhe mostra sobre um registo — com uma exceção importante, abordada abaixo — está dentro do ficheiro, e um analisador adequado pode lê-lo em qualquer lugar. O visualizador EVTX deste site executa esse analisador (a crate evtx de Rust, compilada para WebAssembly) no separador do seu navegador, porque os registos de eventos nomeiam utilizadores, máquinas e endereços IP e não devem ser enviados para um site conversor qualquer, tal como uma captura de pacotes também não deve. O que se segue é o método de trabalho, não o manual da ferramenta: o que observar, por que ordem, e o que os campos lhe dirão e não dirão.

O que está realmente dentro de um ficheiro .evtx

Um ficheiro .evtx é um cabeçalho de 4096 bytes seguido de uma sequência de blocos de 64 KB. Cada bloco contém uma série de registos de eventos, e cada registo é guardado como XML binário (BinXML): um bloco System preenchido pelo sistema operativo, mais a carga própria do fornecedor como EventData ou UserData. Abra um registo e encontrará campos, não prosa — EventID 4625, um carimbo de data/hora, um canal e valores com nome como IpAddress, TargetUserName e LogonType. Esses campos são a prova. São também tudo o que um analisador numa máquina alheia pode honestamente dar-lhe.

Eis a exceção, e ela condiciona tudo o resto neste guia: a frase que o Visualizador de Eventos mostra — «Uma conta falhou ao iniciar sessão» — não está no ficheiro. O Windows gera-a no momento da visualização a partir das DLL de mensagens que pertencem a cada fornecedor e vivem na máquina que escreveu o registo. É por isso que os valores de dados por vezes se parecem com %%14592: são referências a uma tabela de mensagens que o ficheiro não transporta. Um visualizador noutra máquina pode mostrar-lhe cada campo que o evento registou, e o seu XML em bruto exatamente como está guardado — mas uma ferramenta que apresenta um texto de mensagem polido para o .evtx de outra pessoa está a reconstruí-lo a partir das suas próprias cópias das DLL ou a adivinhá-lo. Primeiro os campos, a prosa no fim: é essa a ordem honesta.

Mais um facto estrutural que vale a pena conhecer antes de citar números: os blocos do ficheiro são independentes. Um registo extraído de uma imagem de disco, ou copiado de uma unidade a morrer, tem frequentemente blocos individuais que já não podem ser analisados. Um bom leitor assinala cada bloco danificado com o seu deslocamento em bytes e lê tudo o que o rodeia. O silêncio neste ponto — uma ferramenta que devolve um registo mais curto e não diz nada — é a forma como os registos desaparecem silenciosamente de uma investigação.

Comece pelo bloco System

O bloco System de cada registo transporta o mesmo esqueleto: Provider (que componente o escreveu), EventID (o que aconteceu, na numeração desse fornecedor), Level (de 1 Crítico a 5 Detalhado, com 0 para os eventos que não têm nível), Channel (Security, System, Application e as centenas de registos operacionais sob Microsoft-Windows-*), Computer, um carimbo de data/hora em UTC e o EventRecordID. A triagem começa por ordenar um registo inteiro segundo esse esqueleto: quantos registos, em que intervalo de tempo, de que canais, dominados por que ID de evento. Um registo de Segurança que é 80 % um único ID de evento é normalmente uma história sobre essa única coisa — uma firewall a decidir, um serviço a autenticar-se em ciclo — e o resumo diz-lhe isso antes de ler um único registo.

Cite o EventRecordID do bloco System quando fizer referência a um registo. Os ficheiros extraídos, selecionados ou reexportados podem ter os cabeçalhos de registo renumerados pela ferramenta que os produziu, enquanto o bloco System mantém o ID que a máquina atribuiu originalmente — a diferença entre «registo 7 deste excerto» e «EventRecordID 319457858 no registo original» importa no momento em que alguém tenta reproduzir a sua conclusão. Os carimbos de data/hora merecem o mesmo cuidado: dentro do ficheiro estão em UTC, sempre. O Visualizador de Eventos converte-os para a hora local da máquina que abrir o registo, e é por isso que duas capturas de ecrã do mesmo registo podem diferir em horas. Escolha UTC para o relatório e diga isso.

Quatro ID de evento que ganham o seu lugar

1102 — o registo de auditoria foi limpo. O registo de Segurança regista o seu próprio apagamento, como primeiro evento do novo registo. Os seus campos nomeiam o utilizador que o limpou. Num incidente, um 1102 é ao mesmo tempo prova e fronteira: tudo o que está antes dele nesse registo desapareceu do ficheiro que tem, e o próprio apagamento é um facto que merece uma linha no relatório. Se o registo mais antigo de um ficheiro for um 1102 com um carimbo de data/hora dentro da sua janela de interesse, diga-o antes que alguém construa uma teoria sobre a ausência de eventos anteriores.

4624 e 4625 — inícios de sessão, bem e mal sucedidos. São os cavalos de batalha das investigações de contas. Os campos que importam são TargetUserName, IpAddress e, acima de tudo, LogonType: 3 é um início de sessão de rede, 10 é Ambiente de Trabalho Remoto, 2 é um início de sessão interativo na consola e 7 é um desbloqueio. Um padrão de força bruta lê-se como uma rajada de 4625 contra uma conta a partir de um endereço, seguida — o momento que importa — de um 4624. Um único 4625 é um erro de escrita; o sinal é a forma da sequência, e é por isso que se filtra e se conta em vez de percorrer.

4688 — foi criado um processo. Quando a política de auditoria o regista, cada 4688 nomeia o novo processo (NewProcessName), a conta que o lançou e frequentemente o processo pai — a matéria-prima de «o que correu nesta máquina, e quando». Dois cuidados mantêm-no honesto: o 4688 só existe se a «Auditoria de Criação de Processos» estava ativada na máquina de origem (a sua ausência não prova nada sobre o que correu), e a captura da linha de comandos é outra definição separada. Trate um rasto rico de 4688 como um presente, não como um direito.

Estes quatro são um conjunto de partida, não um programa — o irmão de início de sessão especial do 4624, o 4672, o início de sessão com credenciais explícitas 4648 e a instalação de serviços 7045 no registo System são as paragens seguintes habituais. Mas uma parte notável das perguntas do primeiro dia — o registo foi limpo, quem entrou, de onde, e o que executou — é respondida apenas pelo 1102, 4624, 4625 e 4688.

O que os campos não lhe podem dizer

A disciplina sobre a ausência é a maior parte do trabalho com registos. O ficheiro não pode mostrar-lhe eventos que a máquina de origem nunca registou: a política de auditoria decide o que existe, e uma máquina com a configuração predefinida regista muito menos do que um investigador espera. Não pode mostrar-lhe o texto das mensagens, como visto acima — uma referência %% é um ponteiro para uma cadeia numa máquina que não tem. Não pode, por si só, provar adulteração nem a sua ausência: lacunas nos ID de registo aparecem tanto em ficheiros extraídos honestamente como em registos limpos, e é por isso que o sinal em que se apoiar é o registo 1102 explícito, e não uma lacuna.

E um registo é uma única testemunha. Os carimbos de data/hora vêm do relógio da máquina de origem, que pode ter estado errado; as contas aparecem com os nomes que a máquina conhecia; o IP de um início de sessão de rede é o endereço que a máquina viu, com NAT e VPN incluídos. Os campos são exatamente o que a máquina registou — nem menos, e a disciplina é lembrar-se de que também não são mais.

Uma rotina de triagem de cinco minutos

Primeiro minuto: abra o ficheiro no visualizador EVTX e leia o resumo antes de qualquer registo — total, intervalo de tempo, canais e os principais ID de evento. Tome nota de quaisquer blocos que o visualizador assinale como ilegíveis, com os seus deslocamentos; essa ressalva pertence às suas notas desde o início, não como nota de rodapé depois.

Segundo minuto: verifique o 1102. Se o registo foi limpo, toda a sua abordagem muda, e a hora da limpeza e a conta são os seus primeiros factos sólidos. Terceiro minuto: filtre os 4625 e observe a forma — contagem por conta, por endereço de origem. Uma rajada seguida de um 4624 para a mesma conta a partir do mesmo endereço é a conclusão; tome nota dos carimbos de data/hora exatos. Quarto minuto: com a janela suspeita fixada, filtre os 4688 (e os 4624 de tipo 10, se o acesso remoto estiver em questão) dentro dessa janela e liste o que correu e quem iniciou sessão. Quinto minuto: exporte os registos filtrados como JSON ou CSV e escreva o parágrafo enquanto os números estão à sua frente — ID de registo, horas em UTC, conta, endereços. A exportação é o seu documento de trabalho; o parágrafo, com a ressalva sobre os blocos ilegíveis e o limite do texto das mensagens, é o entregável.

Essa rotina não encerra uma investigação. Transforma um ficheiro binário alheio em cinco factos citados e numa próxima pergunta defensável, em qualquer máquina que esteja à sua frente — o que é a maior parte do que a triagem alguma vez é.

Perguntas frequentes