Nesta postagem eu vou mostrar como criar um backdoor simples para um dispositivo Android com o Metasploit e vou fazer uma pequena análise sobre o apk gerado.
Observação:
O conteúdo apresentado nesta postagem deve ser reproduzido apenas em um ambiente no qual você possui autorização para a realização de testes de segurança.
O conteúdo apresentado nesta postagem deve ser reproduzido apenas em um ambiente no qual você possui autorização para a realização de testes de segurança.
Gerando um Backdoor
Um backdoor (Reverse TCP) para Android pode ser facilmente gerado com o Metasploit. O msfvenom pode ser utilizado para gerar um apk malicioso (Ver Figura 01).
 |
| Figura 01: Msfvenom |
Vou utilizar o adb para instalar o backdoor em um simulador (Ver Figura 02).
 |
| Figura 02: Utilizando Abd para instalar backdoor |
Rodando o Backdoor
Uma vez instalado, o backdoor vai aparecer da seguinte maneira no dispostivo:
 |
| Figura 03: Backdoor no Simulador |
Antes de executar o backdoor, você deve gerar um 'handler' no Metasploit para receber a conexão reversa realizada pelo apk malicioso (Ver Figura 04).
 |
| Figura 04: Criando Handler |
Execute o backdoor no simulador (ou dispositivo) e veja uma sessão sendo aberta no Metasploit (Ver Figura 05)
 |
| Figura 05: Sessão Aberta |
Analisando o Backdoor
Vamos agora dar uma olhada melhor no apk gerado pelo Metasploit e ver se conseguimos aprender algumas coisas com ele.
Taxa de Detecção
Vamos primeiro começar dando uma verificada na taxa de detecção do apk malicioso. A figura 06 apresenta os resultados do VirusTotal para o backdoor.
 |
| Figura 06: VirusTotal |
O apk gerado apresenta uma taxa de detecção significativa (14 entre 54). A lista completa de detecção pode ser visualizada em https://www.virustotal.com/en/file/ae2133416ecddbe53390b46f6708200a0d2b6515800dfe6823bf5d1b8789640e/analysis/1402957750/
AndroidManifest.xml
O próximo passo é verificar o arquivo AndroidManifest.xml localizado dentro do apk. A figura 07 apresenta algumas informações básicas como nome do pacote e permissões necessárias para o malware.
 |
| Figura 07: AndroidManifest.xml 01 |
A partir da figura 07, é possível verificar que o malware é identificado pelo nome de pacote "com.metasploit.stage" (bastante sugestivo hehe) e utiliza um grande número de permissões (Ex: INTERNET, SEND_SMS e CAMERA). O apk apresenta uma única Activity: ".MainActivity" (ver figura 08).
 |
| Figura 08: AndroidManifest.xml 02 |
Decompilação (Parte 01)
O próximo passo é decompilar o apk e analisar o código fonte da aplicação. A Figura 09 apresenta as classes presentes no apk. É possível verificar a presença de MainActivity (declarada no Manifest.xml) e mais 3 classes (BuildConfig, LoadStage e R).
 |
| Figura 09: Classes |
Vamos começar analisando a classe MainActivity. A partir da figura 10, é possível verificar de que o método 'AsyncTask()' é chamado logo no momento de criação de MainActivity. O método 'reverseTCP()' é chamado por 'AsyncTask()'.
 |
| Figura 10: MainActivity |
A figura 11 apresenta o método 'reverseTCP()' e algumas variáveis globais (LHOST e LPORT). O método 'reverseTCP' cria um socket (gerando uma conexão para LHOST) e chama a classe 'LoadStage'.
 |
| Figura 11: MainActivity 02 |
A classe 'LoadStage' apresenta 2 métodos interessantes:
- randomJarName: Cria uma String de 20 caracteres aleatórios que vai servir de nome para um arquivo '.jar'.
- start: Cria um novo arquivo '.jar' () e baixa o conteúdo de um novo arquivo '.dex' pela rede. DexClassLoader e Reflection são utilizados para executar o novo arquivo '.dex' (ultimas 3 linhas do método 'start').
 |
| Figura 12: LoadStage |
Decompilação (Parte 02)
Nesta segunda parte vamos analisar o novo '.dex' gerado no dispositivo. A figura 13 apresenta os novos arquivos criados na pasta do aplicativo (observe os nomes aleatórios utilizados nos arquivos).
 |
| Figura 13: Novos arquivos gerados (jar e dex) |
Eu encontrei um pequeno problema durante o processo de decompilação do arquivo '.dex' (ver figura 14). O arquivo na realidade trata-se de ser um '.odex' (tipo otimizado de '.dex').
Para decompilar um arquivo '.odex' vamos ter que tomar alguns passos:
Agora podemos analisar melhor o '.dex' baixado e executado pelo backdoor. O arquivo '.jar' agora é recriado sem problemas. A Figura 15 apresenta as classes presentes (Shell, Stage e StreamForwarder).
Os nomes dos pacotes são novamente bem sugestivos (hehe). A partir da figura 16, é possível verificar que a classe Shell cria um novo processo ('sh') e realiza uma śerie de 'redirecionamentos' para executar cada instrução recebida pelo atacante e retornar a resposta de cada comando executado.
Nesta postagem eu falei um pouco sobre backdoors em Android (gerados pelo Metasploit) e fiz uma pequena análise sobre eles. O processo de decompilação pode ser reproduzido para outros tipos de malware. Por favor escrevam suas sugestões e comentários!
 |
| Figura 14: Erro na decompilação (Arquivo 'odex') |
Para decompilar um arquivo '.odex' vamos ter que tomar alguns passos:
- Copiar os arquivos de '/system/framework' para a máquina local
- "adb pull /system/framework/ /tmp/framework/"
- Obter arquivos 'smali' utilizando o baksmali.jar
- "java -jar baksmali-2.0.3.jar -a 15 -x /tmp/nome_aleatorio.dex -d /tmp/framework/ -o Backdoor"
- Reconstruir o 'classes.dex' com smali.jar
- "java -jar smali-2.0.3.jar -o classes.dex Backdoor/"
Decompilação (Parte 3)
Agora podemos analisar melhor o '.dex' baixado e executado pelo backdoor. O arquivo '.jar' agora é recriado sem problemas. A Figura 15 apresenta as classes presentes (Shell, Stage e StreamForwarder).
 |
| Figura 15: Classes 02 |
 |
| Figura 16: Classe Shell |
Conclusão
Nesta postagem eu falei um pouco sobre backdoors em Android (gerados pelo Metasploit) e fiz uma pequena análise sobre eles. O processo de decompilação pode ser reproduzido para outros tipos de malware. Por favor escrevam suas sugestões e comentários!
Obrigado :)
Keep Hacking!
.png)
