Neste artigo, será apresentado um cenário prático de investigação em ambiente Windows, com foco na análise de logs para identificar ações potencialmente maliciosas. Por meio da coleta e correlação de eventos do sistema operacional e do Active Directory, serão examinadas atividades relacionadas a autenticação, uso indevido de credenciais, criação de processos suspeitos e mecanismos de persistência. A interpretação desses registros permitirá reconstruir a linha do tempo do incidente, identificar possíveis vetores de ataque e compreender as técnicas utilizadas pelo adversário.

Ataques a sistemas Windows são comuns porque esse é o sistema operacional mais utilizado em ambientes corporativos. Isso ocorre pela familiaridade de usuários com a plataforma e pela ampla compatibilidade com serviços e aplicações. Como consequência, o Windows costuma ser um alvo frequente.

Podemos relacionar esse cenário a algumas técnicas do MITRE ATT&CK, para entender melhor esse tipo de exploração:

• T1136 — Criação de contas com privilégio administrativo para manter persistência de acesso.
• T1098 — Gerenciamento de contas e grupos para facilitar logins futuros.

Como funciona um ataque de autenticação e persistência?

Em geral, o atacante tenta invadir máquinas de usuários ou servidores explorando falhas no processo de autenticação (por exemplo, senhas fracas, força bruta ou vulnerabilidades). Quando o acesso inicial é obtido, o próximo passo costuma ser estabelecer persistência, isto é, mecanismos que permitam retornar ao ambiente posteriormente.

Com o acesso garantido, o atacante pode:

• criar um novo usuário;
• escalar privilégios desse usuário;
• conceder permissões administrativas;
• configurar comunicação com servidores de comando e controle (C2), que podem ser usados para exfiltração de dados ou para transformar o equipamento em parte de uma botnet.

Neste artigo, apresento um laboratório em que identificamos essas ações a partir da análise de logs do Windows.

Eventos de autenticação: 4624 e 4625

Para investigar anomalias de autenticação, dois Event IDs são especialmente úteis:

• 4624 — Logon bem-sucedido
• 4625 — Falha de logon

Na primeira etapa do laboratório, foi solicitado identificar qual endereço IP estava realizando um ataque de força bruta no sistema. Para isso, abri o Event Viewer e filtrei os logs pelo ID 4625 (falhas), pois antes da força bruta ter sucesso, o número de tentativas inválidas costuma ser alto:

Após filtrar os eventos 4625, identifiquei diversas tentativas com diferentes usuários, todas vindas do IP 10.10.53.248. Com isso, já foi possível apontar o IP suspeito na rede.

Identificando o acesso bem-sucedido e a conta comprometida

Em seguida, o laboratório indicava que, em algum momento, o atacante teve sucesso. Foi solicitada a identificação da conta comprometida.

Então filtrei os logs pelo ID 4624 para verificar acessos permitidos ao servidor:

Aqui aparece um logon originado do IP 10.10.53.248 usando a conta Administrator. A partir desse ponto, o atacante já tem acesso e, potencialmente, liberdade para criar um novo usuário e escalar privilégios.

Mas por que criar um usuário se já existe acesso como Administrator? Porque ações frequentes diretamente com a conta Administrator tendem a chamar mais atenção. Criar uma conta "secundária" é uma forma comum de reduzir suspeitas e manter persistência.

Eventos úteis para detectar manipulação de contas e grupos

Antes de seguir com os desafios, vale destacar alguns IDs importantes para identificar ações relacionadas a contas e grupos:

• 4720 / 4722 / 4738 — Conta criada, ativada e alterada
• 4725 / 4726 — Conta desativada e conta excluída
• 4723 / 4724 — Usuário alterou a senha e senha redefinida
• 4732 / 4733 — Usuário adicionado e removido de um grupo

Conta criada após o acesso: 4720

Foi solicitado identificar qual conta foi criada após o acesso bem-sucedido. Para isso, analisei os eventos após o último 4624 (momento do acesso) e busquei um evento de criação de conta (4720) com origem na máquina comprometida.

Com isso, descobri que o usuário criado foi support:

Escalação de privilégios via grupos: 4732

Como a criação do usuário por si só não garante privilégios, o próximo passo foi identificar em qual grupo o atacante adicionou essa conta.

Seguindo a linha do tempo a partir do evento 4720, procurei eventos 4732, que indicam adição a grupos:

Foi possível identificar que o usuário support foi adicionado ao grupo de Administrators. A partir daí, o atacante pode parar de usar a conta Administrator e utilizar a conta criada para continuar as ações.

Persistência via serviços e tarefas agendadas (4697 e 4698)

Após escalar privilégios, o atacante pode criar serviços e tarefas para manter a persistência.

Nesta etapa, procuramos eventos relacionados à criação de serviços e tarefas:

• 4697 — Criação de serviço
• 4698 — Criação de tarefa agendada

Para enriquecer a análise, também é possível usar o Sysmon, que fornece logs mais detalhados. No Sysmon, alguns eventos relevantes aparecem com IDs diferentes (por exemplo, criação de processo como ID 1).

Comecei procurando eventos 4697 que pareciam fora do padrão do sistema e identifiquei um processo com um nome incomum:

A ação foi executada por um usuário com privilégios às 07:09. Analisei outros eventos 4697 no mesmo período e não encontrei mais nada que se destacasse.

Tarefa agendada maliciosa: 4698

Em seguida, foi solicitado identificar a tarefa agendada criada para manter um malware ativo. Procurei eventos 4698 após as 07:09 e encontrei uma tarefa com nome que poderia facilmente se passar por algo confiável:

O que confirmou a suspeita foi o campo de comando, que chamava o malware troy.exe:

Alterações em arquivos e registro: 4656/4657 e Sysmon 11/13

No Windows, também existem eventos úteis para mudanças em arquivos e no registro:

• 4656 — Acesso/alteração de arquivos
• 4657 — Alteração de registro

No Sysmon, esses eventos costumam aparecer de forma mais detalhada, por exemplo:

• Sysmon ID 11 — Criação de arquivo
• Sysmon ID 13 — Modificação de valor no registro

Nesta etapa, foi solicitado identificar um malware no sistema e verificar o que ele apresentava ao ser executado.

Comecei filtrando os logs pelo Sysmon ID 11 (se é malware, algo foi criado). Assim identifiquei que o atacante criou um arquivo .cmd e o colocou na pasta de inicialização, para execução automática após reinicialização:

Identificando a última linha exibida pelo malware

Depois, precisamos identificar qual era a última linha apresentada quando o comando do malware era executado.

Voltei aos logs e filtrei pelo Sysmon ID 1 (criação de processos), buscando algo incomum. Em um dos eventos, o campo ParentCommandLine mostrava que o arquivo chamado era o odin.cmd, e o próprio log revelava a linha de comando executada:

A última linha exibida quando o arquivo é executado é:

Done doing bad stuff!

Desafio final: malware "kitten" e alteração no registro

O último desafio foi capturar uma flag em um malware chamado kitten. Para isso, filtrei os logs pelo Sysmon ID 13 na expectativa de encontrar alterações no registro.

Encontrei um evento indicando que o executável modificou uma chave no registro:

O desafio pedia o nome da chave do malware, e o próprio log trazia a resposta: Basket.

E a flag do desafio foi:

THM{persisting_in_basket!}

Conclusão

Como aprendizado, este laboratório reforça que o Windows possui uma fonte de logs muito rica. Quando analisados corretamente, esses registros permitem detectar e responder a tentativas de autenticação indevida, criação de contas, elevação de privilégios e mecanismos de persistência.

Quando combinadas com regras e correlações em um SIEM, essas análises ajudam a gerar alertas sobre mudanças e criações suspeitas, permitindo que a equipe de segurança se antecipe e reduza o impacto de um ataque.

Espero que a leitura tenha sido agradável. Obrigado por ler até aqui!

Laboratorio realizado no tryhackme.com