Como estudar casos comuns de injeção de código em malware

Como estudar casos comuns de injeção de código em malware

Confira um exemplo de como estudar casos de injeção de código em malware, analisando aplicativos de exemplo.

Confira um exemplo de como estudar casos de injeção de código em malware, analisando aplicativos de exemplo.

A melhor maneira de entender como a injeção de processos funciona é através da visualização do código em operação. Se não tivermos acesso a várias amostras de executáveis ​​maliciosos, a alternativa é analisar os aplicativos de exemplo, que apresentam as técnicas que são comumente usadas no malware.

A pesquisadora Hasherezade publicou vários exemplos dessas técnicas, cujos projetos podem ser baixados do seu github. Para poder compilá-los, é necessário ter alguma versão do Visual Studio e do CMake instalados.

 

No meu caso, eu baixei uma versão gratuita do Visual Studio 2012. Você pode baixá-lo aqui, sendo necessário realizar login com a sua conta do Live ou criar uma no momento. Então, com o CMake (que pode ser baixado aqui), serão gerados arquivos da solução do Visual Studio de acordo com o ambiente instalado em seus computadores.

Para começar, vamos tomar como exemplo um caso de Process Replacement (RunPE). Resumindo, a imagem de um processo na memória é substituída pela de um executável malicioso.

 

A imagem anterior mostra como devemos configurar o CMake para apontar para a pasta src do projeto run_pe. Além disso, criamos uma pasta build, que conterá a solução gerada pelo CMake. Por último, selecionamos o Visual Studio 2012 (no nosso caso) e clicamos no botão Gerar.

 

Se tudo sair bem, vamos para a pasta build que criamos anteriormente e lá encontraremos o arquivo da solução do Visual Studio que foi gerado.

 

Ao abri-lo, encontraremos o código que nos interessa no projeto RunPE, embora, no momento de compilar a solução, isso pode ser feito no explorador de Soluções, executando ‘Build Solution’.

 

Antes de gerar o executável que realiza a injeção, é aconselhável escolher a configuração ‘Release‘ para a compilação. Também é possível gerar a versão ‘Debug‘ para poder colocar breakpoints e seguir o rastreamento da execução dentro do mesmo ambiente do Visual Studio.

 

Na imagem anterior, vemos as chamadas típicas para o API do Windows relacionado com o Process Replacement. Como um passo adicional, é interessante usar um debugger externo (OllyDbg 2 no meu caso) e ver se podemos dumpear o executável injetado da memória, antes do ResumeThread ser executado, fazendo o dump do buffer em que é copiado, ou depois do ResumeThread – por exemplo, fazendo um attach ao processo injetado (calc.exe).

 

Deixarei para você o restante dos exemplos. Recomendo que você tente analisar os executáveis como se fossem uma amostra maliciosa desconhecida. Caso, em algum momento, você se sinta perdido ou não saiba como avançar, tenha como base o código-fonte.

Happy debugging!

Discussão