Write Up - Lockdown Lab | CyberDefenders

Hoje resolvi trazer as soluções de um CTF bastante interessante e relativamente simples da plataforma CyberDefenders, o Lockdown Lab.

O principal objetivo deste conteúdo não é apenas resolver o CTF, mas também ensinar o público iniciante a como chegar às respostas seguindo um raciocínio de análise de incidentes, como se estivéssemos lidando com um caso real, e não apenas buscando obter uma flag.

Você pode também ver esse Write Up em nossa playlist no Youtube:

Dito isso, vamos começar.

Cenário O SOC da TechNova Systems detectou tráfego de saída suspeito proveniente de um servidor IIS exposto à internet em sua plataforma de nuvem — atividade sugestiva do implante de um web shell e de conexões furtivas com um host desconhecido. Como perito forense, você tem em mãos três artefatos críticos: um PCAP que captura o tráfego inicial, uma imagem completa da memória do servidor e uma amostra de malware recuperada do disco. Reconstituía a intrusão e todas as atividades do atacante para que a TechNova possa conter a violação e fortalecer suas defesas.

O cenário já nos fornece algumas informações interessantes, como o servidor IIS, então podemos dizer que é um servidor windows infectado, e temos 3 arquivos para analisar. Vamos as perguntas:

Analise de PCAP

1. Após inundar o host IIS com sondagens em rápida sucessão, o atacante revela sua origem. Qual endereço IP gerou esse tráfego de reconhecimento?

Uma das primeiras ferramentas que utilizo ao analisar um arquivo PCAP é o Wireshark.

Ao abrir o PCAP no Wireshark, um dos meus pontos de partida é acessar Analyze → Expert Information, onde é possível visualizar alertas e indicadores relevantes que podem auxiliar na investigação.

O que imediatamente chamou minha atenção foi a presença de um Warning relacionado a diversas respostas RST, o que pode indicar tentativas de scan, conexões interrompidas abruptamente ou comportamento anômalo na comunicação.

Ao analisar alguns desses eventos, é possível perceber que se tratam de uma sequência de portas, sempre envolvendo os mesmos endereços IP: 10.0.2.15 respondendo para 10.0.2.4. Esse padrão é característico de um scan de portas, com origem no endereço 10.0.2.4.

Além disso, costumo verificar Statistics → Conversations → IPv4, pois essa visão permite identificar quais hosts trocaram a maior quantidade de pacotes. Nesse caso, é possível confirmar o comportamento suspeito entre 10.0.2.4 e 10.0.2.15, com mais de 6.000 pacotes trocados entre ambos, reforçando a hipótese de atividade de reconhecimento.

Para reforçar a confirmação de que um scan de portas está ocorrendo, podemos aplicar o filtro

ip.src == 10.0.2.4 && ip.dst == 10.0.2.15

no Wireshark e observar a sequência de portas de destino sendo acessadas.

Outro forte indicador desse comportamento é o fato de a mesma porta de origem estar tentando se conectar a diversas portas de destino em um curto intervalo de tempo, muitas vezes dentro do mesmo segundo, o que é típico de atividades automatizadas de reconhecimento.

FLAG: 10.0.2.4

2. Ao concentrar-se em um único serviço aberto para obter um ponto inicial de acesso, o atacante realiza uma enumeração direcionada. Qual ID da técnica do MITRE ATT&CK abrange essa atividade?

Com uma pesquisa simples no Google, é possível identificar rapidamente o ID da técnica correspondente.

FLAG: T1046

3. Ao analisar o tráfego SMB, você observa duas requisições Tree Connect consecutivas que revelam os primeiros compartilhamentos que o invasor sondou no host IIS. Quais são os dois caminhos UNC completos que foram acessados?

Ao acessar Statistics → Protocol Hierarchy com o filtro

ip.src == 10.0.2.4 && ip.dst == 10.0.2.15 

aplicado, é possível observar que há uma quantidade significativa de bytes trafegados utilizando o protocolo SMB2, indicando atividade relevante desse serviço durante a comunicação analisada.

Então, ao aplicar o filtro

ip.src == 10.0.2.4 && ip.dst == 10.0.2.15 && smb2

é possível observar o trafego SMB2 e identificar os diretorios acessados:

FLAG: \\10.0.2.15\Documents, \\10.0.2.15\IPC$

4. Dentro do compartilhamento, o atacante implanta um payload acessível via web que concederá execução remota de código. Qual é o nome do arquivo malicioso que foi enviado e qual o tamanho em bytes especificado na requisição SMB2 Write correspondente?

Ao analisar mais detalhadamente os pacotes SMB2, é possível identificar uma requisição de criação do arquivo shell.aspx, bem como o tamanho do arquivo especificado na operação.

FLAG: shell.aspx, 1015024

5. O shell recém-implantado se conecta de volta ao atacante por meio de uma porta incomum, porém amigável a firewalls. Qual porta de escuta o atacante utilizou para o reverse shell?

Aqui temos duas abordagens possíveis. A primeira consiste em identificar o momento em que o shell.aspx foi acessado e, em seguida, procurar por conexões de saída originadas do IIS.

Realizando uma busca simples, é possível identificar o momento exato em que a chamada ao shell ocorreu:

Em seguida, ao filtrar pelo endereço 10.0.2.15 e analisar as conexões que ocorreram logo após o acesso ao shell.aspx (ou seja, após a resposta HTTP 200), é possível identificar um tráfego incomum na porta 4443.

Esse comportamento sugere fortemente que a porta 4443 foi utilizada para receber a conexão da shell reversa.

Outra abordagem consiste em acessar File → Export Objects → SMB e realizar o download do arquivo shell.aspx diretamente a partir do tráfego capturado.

Ao abrir o arquivo com o Notepad, é possível identificar rapidamente a seção que contém o shellcode (Shellcode consiste em instruções em assembly representadas em hexadecimal, cujo objetivo é executar determinadas ações no sistema, sendo normalmente injetadas diretamente na memória durante a exploração.).

Copie apenas os valores hexadecimais e, em seguida, acesse o CyberChef para continuar a análise.

Salve o output em um arquivo e utilize o comando strings para analisar o conteúdo. Como o shellcode não utiliza nenhum tipo de criptografia ou ofuscação, é possível visualizar diversas strings em texto claro, uma das strings mostra o socket:

É claro que seria necessária uma análise mais aprofundada para ter 100% de certeza, como o uso de um decompilador ou debugger para observar o comportamento do código. No entanto, para os fins desta análise, vamos assumir que esse é o socket utilizado.

FLAG: 4443

Análise de dump de memória

6. O snapshot de memória captura o kernel do sistema em execução, fornecendo um contexto vital sobre a violação. Qual é o endereço base do kernel presente no dump?

Para a análise de memória, gosto de utilizar o Volatility. Neste caso, optei pelo Volatility 3, executando-o em uma VM Linux (estou utilizando o REMnux).

É possível encontrar o endereço base do kernel executando o seguinte comando:

python3 volatility3/vol.py -f memdump.mem windows.info

FLAG: 0xf80079213000

7. Um serviço confiável executa um executável desconhecido, localizado fora da pilha padrão do IIS, sinalizando um implante de persistência. Qual é o caminho completo final desse executável no disco e qual ID da técnica de persistência do MITRE ATT&CK corresponde a esse comportamento?

Ao que tudo indica, o IIS é o processo pai do malware. Dessa forma, ao analisar os detalhes dos processos e filtrar pelo w3wp.exe (processo legítimo do IIS) é possível observar um processo filho chamado updatenow.exe, o que não representa um comportamento comum para esse serviço.

A linha de comando (cmdline) do processo indica que ele foi iniciado a partir do diretório

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\updatenow.exe.

Esse é um diretório no qual qualquer executável presente é iniciado automaticamente após o login do usuário, caracterizando um mecanismo clássico de persistência.

Com uma pesquisa simples, é possível identificar a técnica correspondente no framework MITRE ATT&CK.

FLAG: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\updatenow.exe, T1547

8. O tráfego de saída da shell reversa é tratado por um processo nativo do Windows que também é responsável por iniciar o executável implantado. Qual é o nome desse processo e sob qual PID ele está sendo executado?

Neste ponto, já poderíamos supor diretamente que se trata do processo w3wp.exe, com PID 4332. No entanto, para confirmar essa hipótese, vamos analisar as conexões de rede utilizando o comando windows.netscan.NetScan.

FLAG: w3wp.exe, 4332

Analise da amostra do Malware

9. A inspeção estática revela que o binário foi empacotado para dificultar a análise. Qual packer foi utilizado para ofuscá-lo?

Uma inspeção simples com a ferramenta Detect It Easy revela a utilização do UPX como packer para ofuscar o binário.

windows

Linux

10. A análise de threat intelligence mostra que o malware está se comunicando periodicamente com seu host de comando e controle (C2). Qual é o nome de domínio totalmente qualificado (FQDN) com o qual ele se conecta?

Nesse ponto, é possível obter o hash do arquivo utilizando o próprio DIE e, em seguida, consultar fontes públicas de threat intelligence, como o VirusTotal, para verificar se se trata de um malware já conhecido e coletar informações adicionais sobre seu comportamento, incluindo infraestrutura de C2 e detecções associadas.

DIE

VirusTotal

FLAG: cp8nl.hyperhost.ua

11. Fontes de inteligência de código aberto (OSINT) associam esse hash a um RAT comercial amplamente conhecido. A qual família de malware essa amostra pertence

Nesse caso, os family labels exibidos pelo VirusTotal não apresentam diretamente a resposta esperada para o flag. No entanto, ao consultar a Alibaba Threat Intelligence, é possível identificar a família AgentTesla, que é um malware de acesso remoto (RAT) amplamente conhecido, utilizado para espionagem e exfiltração de dados.

Além disso, outra prática que considero bastante útil é pesquisar diretamente o hash no Google, a fim de verificar quais resultados e referências públicas estão associadas a ele.

Um dos resultados retornados foi do repositório MalwareBazaar, uma fonte amplamente conhecida por catalogar diversas amostras de malware. Por meio dele, foi possível confirmar que a amostra pertence à família AgentTesla.

FLAG: AgentTesla

Extra

Em alguns casos, podemos nos deparar com variantes de malware para as quais não existem informações facilmente disponíveis na internet. Nessas situações, é possível realizar uma análise estática básica e rápida para determinar se o binário é ou não malicioso.

No caso deste binário, ele está empacotado com UPX. Se tentarmos analisá-lo diretamente nesse estado, não conseguiremos observar muitos detalhes relevantes. No entanto, é possível remover o packer utilizando o próprio utilitário do UPX, o que facilita análises posteriores.

Em seguida, podemos utilizar uma ferramenta como o PEstudio para coletar informações adicionais sobre o binário.

Ao analisar a seção de imports, é possível observar as APIs do Windows utilizadas pelo executável. O próprio PEstudio já destaca algumas delas como suspeitas ou potencialmente maliciosas.

A presença dessas APIs sugere que o binário realiza diversas ações no sistema, como acesso a arquivos, criação de processos em memória, entre outras atividades. Esse conjunto de comportamentos fornece um forte indicativo de que se trata de malware.

A análise de strings deste binário não trouxe muitas informações relevantes, mas ainda assim é uma etapa importante, pois permite buscar por comandos, endereços IP, domínios, URLs, entre outros indicadores úteis.

Outra particularidade interessante deste binário é que ele foi desenvolvido com AutoIt, o que pode ser observado na seção de resources. Nesses casos, é possível utilizar a ferramenta Exe2Aut para extrair e analisar o código-fonte do script AutoIt, facilitando a compreensão do comportamento do malware.

O código é extenso, criptografado e repleto de código lixo, o que explica por que o comando strings não foi muito útil neste caso. Ainda assim, a partir dele seria possível analisar o código em profundidade e compreender melhor o comportamento do malware, algo que fica fora do escopo deste post. :)